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Shadow function box interface for use in process control network e.g. chemical 
or petroleum process has memory receiving data pertaining to external function 
block, according to configuration protocol of internal function block 
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Abstract 



A shadow function block (108) has a communications port with an input that communicates with an external function 
block (112) via the communication network. This is done to receive data pertaining to the external function block. A 
memory (156) stores the received data pertaining to the external function block, according to a configuration protocol 
of the internal function block (1 1 52). Independent claims are also included for (1 ) A controller'adapted to be 
communicatively coupled to a number of field devices, and (2) A method of implementing a control routine within a 
process controller. ■ 
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Die folgenden Angaben sind den vom Anmelder eingereichten Unterlagen entnommen 

® Interface in Form eines Schattenfunktionsblockes fur die Verwendung in einem Prozessregelnetzwerk 

(57) Ein Prozeftkontroller, der kommunikativ mit einer exter- 
nen Bereichsvorrichtung uber ein Kommunikationsnetz- 
werk gekoppelt ist, verwendet einen Schattenfunkt ions- 
block, der innerhalb eines Prozefckontrollers angeordnet 
ist, um eine Implementierung einer Steuer- oder Regel- 

routine zu ermoglichen, die sowohl einen internen Funk- , 
. tionsblock, der innerhalb des Prozefckontrollers angeord- 
net ist, als auch einen externen Funktionsblock, der inner- 
halb der externen Bereichsvorrichtung angeordnet ist, 
verwendet. Der Schattenfunktionsblock enthalt einen 
Kommunikationsport, der mit dem externen Funktions- 
block uber das Kommunikationsnetzwerk kommuniziert, 
um dadurch Daten, die den externen Funktionsblock be- 
treffen, zu empfangen, enthalt einen Speicher, der die 
empfangenen Daten gemafc einem Konfigurationsproto- 
koll des internen Funktionsblocks separiert, und einen 
Ausgang, der die gespeicherten externen Funktionsblock- 
daten in den internen Funktionsblock gemaft dem Konfi- 
J gurationsprotokoll des internen Funktionsblocks liefert. 
Der Kommunikationsport des Interface-Funktionsblocks 
kann einen Ausgang enthalten", der Daten, die durch den 
Kontroller oder den internen Funktionsblock erzeugt wor- 
den sind, zu dem externen Funktionsblock unter Verwen- 
dung des Kommunikationsprotokolls sendet, welches 
dem externen Funktionsblock zugeordnet ist. 
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Beschreibung 

Die v'orliegende Erfindung betrifft ProzeBregelnetzwerke 
und spezieUer einen ProzeBkontroller, der Schattenfunkti- 
onsblocke verwendet, tfm Informationen wiederzugeben, 
die externen Funktionsblocken zugeordnet sind, welche in 
einem ProzeBregelnetzwerk verteilt sind. 

ProzeBregelnetzwerke, wie beispielsweise soiche, die in 
chemischen, Mineralol- oder anderen Prozessen verwendet 
werden, enthalten im allgemeinen einen zentralisierten Pro- 
zeBkontroller; der kommunikativ mit einer oder mehreren 
Gebiets- oder Bereichsvorrichtungen gekoppelt ist, die bei- 
spielsweise Ventilstellglieder, Schalter, Sensoren (wie z. B. 
Temperatur-, Druck- und Stromungsratensensoren) usw. 
sein konnen. Diese Bereichsvorrichtungen konnen Steuer- 
funktionen innerhalb des Prozesses durchflihren (wie das 
Offhen oder SchlieBen eines Ventils), konnen Messungen 
innerhalb des Prozesses vornehmen, die fur die Steuerung 
oder Regelung der Arbeitsweise des Prozesses verwendet 
werden, oder konnen irgendeine andere gewiinschte Funk- 
tion innerhalb des Prozesses ausfiihren. Proz.eBregler wur- 
den in historischer Weise an die Bereichsvorrichtungen uber 
eine oder mehrere analoge Signalleitungen oder Busse ange- 
schlossen, die beispielsweise 4-20 mA (Milliampere) Si- 
gnale zu und von den Bereichsvorrichtungen leiten. Allge- 
mein gesagt, empfangt der ProzeBkontroller Signale, welche 
die Messungen angeben, die durch einen oder durch meh- 
rere Bereichsvorrichtungen vorgenommen wurden und/oder 
andere Inforfnationen anzeigen, die zu einer oder zu mehre- 
ren Bereichsvorrichtungen gehoren, und er verwendet diese 
Informationen, um eine typische komplexe Steuerroutine zu 
implementieren, und erzeugt dann Steuersignale, die uber 
die analogen Signalbusse zu einer oder mehreren der Be- 
reichsvorrichtungen" gesendet werden, um dadurch den Be- 
trieb des Prozesses zu steuern. 

Kiirzlich kamBewegung in die ProzeBregel- oder -steuer- 
industrie, um bereichsbasierende digitale Kommunikatio- 
nen in der ProzeBregelumgebung zu implementieren, Bei- 
spielsweise hat die ProzeBregelindustrie eine Anzahl von of- 
fenen, digitalen oder kombinierten digitalen und analogen 
Standardkommunikationsprotokollen entwickelt, wie bei- 
spielsweise die HART®, PROFIBUS®, WORLDHP®, De- 
vice-Net® und CAN-Protokolle. Diese digitalen Kommuni- 
kationsprotokolle ermoglichen es mehreren Bereichsvor- 
richtungen, an einen bestimmten Bus angeschlossen zu wer- 
den, sie unterstutzen mehrere und schnelle Kommunikatio- 
nen zwischen den Bereichsvorrichtungen und dem Kontrol- 
ler und/oder ermoglichen es den Bereichsvorrichtungen, 
mehrere und unterschiedliche TVpen von Informationen, 
wie beispielsweise Informationen, die den Status und die 
Konflguration der Bereichsvorrichtung selbst betreffen, zu 
dem ProzeBkontroller zu senden. Ferner ermoglichen es 
diese digitalen Standardprotokolle den Bereichsvorrichtun- 
gen, die von unterschiedlichen Herstellern hergestellt wur- 
den, zusammen mit dem gleichen ProzeBregelnetzwerk ver- 
wendet zu werden. 

. Auch gibtes nunmehrBewegung innerhalb der ProzeBre- 
gelindustrie, die ProzeBregelung oder -steuerung zu dezen- 
tralisieren, wodurch die ProzeBkontroller vereinfacht wer- 
den. Eine dezentralisierte Steuerung oder Regelung wird da- 
durch erhalten, daB bereichsmontierte ProzeBsteuervorrich- 
tungen, wie beispielsweise Ventilstellglieder, Sender usw., 
■ eine oder mehrere ProzeBsteuerfunktionen durchflihren, und 
zwar unter Verwendung von Einrichtungeh, die in typischer 
Weise als Funktionsblocke bezeichnet werden, und indem 
dann Daten uber eine Busstruktur fur die Verwendung durch 
andere ProzeBsteueryorrichtungen (oder Funktionsblocke) 
bei der Ausfuhrung anderer Steuerfunktionen iibertragen 



K) 230 A 1 

2 

werden. Um diese Steuerfunktionen zu implementieren, ent- 
halt jede ProzeBsteuervorrichtung in typischer Weise einen 
Mikroprozessor mit der Fahigkeit, einen oder mehrere 
Funktionsblocke zu implementieren, als auch die Fahigkeit, 

5 mit anderen ProzeBsteuervorrichtungen zu kommunizieren, 
und zwar unter Verwendung eines offenen Standardkommu- 
nikationsprotokolls. In dieser Weise konnen Bereichsvor- 
richtungen innerhalb eines ProzeBregelnetzwerks miteinan- 
der verbunden werden, um miteinander zu kommunizieren 

10 und um eine oder mehrere ProzeBsteuerfunktionen unter 
Bildung einer Regelschleife durchzufuhren, und zwar ohne 
Einschreiten eines zentralisierten ProzeBkontrollers. Das ge- 
samtdigitale Zweidraht-Busprotokoll, welches durch die' 
Fieldbus Foundation entworfen wird, bekannt als FOUN- 

15 DAITON (eingetragene Marke) Fieldbus- (im folgenden als 
"Fieldbus" bezeichnet) Protokoll bekannt ist, ist ein offenes 
Kommunikationsprotokoll, welches es den Vorrichtungen, 
die von unterschiedlichen Herstellern stammen, ermoglicht, 
untereinander zusammenzuarbeiten und zu kommunizieren, 

20 und zwar uber einen Standardbus; um eine dezentralisierte. 
Steuerung innerhalb es Prozesses zu bewirken. 

Da digitale Kommunikationsprotokolle und dezentrali- 
sierte Steuerungsschemata (wie soiche, die in der Fieldbus- 
Steuer- oder -Regelumgebung verwendet werden) so neu 

25 sind, verwenden Prozesse, welche diese Protokolle imple- 
mentieren, diese lediglich in einem eingeschrankten Aus^ 
maB. Als ein Ergebnis unterstutzen neuere ProzeBkontroller, 
wie der Delta V- (eingetragene Marke) ProzeBkontroller, der 
durch Fisher-Rosemount Systems hergestellt wird, sowohl 

30 analoge als auch digitale Kommunikationsprotokolle und es 
kann eine Hardware so programmiert werden, um die Steue- 
rung in einem ProzeB zu implementieren, der Bereichsvor- 
richtungen enthalt, die unter Verwendung von analogen 
Standardprotokollen kommunizieren, wie beispielsweise ei- 

35 nem 4-20 mA Protokoll, und unter Verwendung von einem 
.oder mehreren neueren digitalen Protokollen, wie dem 
Fieldbus- Protokoll. 

Es stellten sich jedoch Probleme ein, wenn versucht 
wurde, die Steuerung von analogen und digitalen Bereichs- 

40 vorrichtungen zu integrieren, und zwar speziell bei den 
Fieldbus-Bereichsyorrichtungen in einem ProzeBregelnetz- 
werk, welches einen zentralisierten Kontroller verwendet. 
Da die Steuerfunktionen fur analoge Bereichsvorrichtungen 
und einige digitale Bereichsvorrichtungen innerhalb des 

45 zentralisierten ProzeBkontrollers implementiert sind, wer- 
den alle erforder lichen Informationen uber diese Bereichs- 
vorrichtungen innerhalb des zentralisierten ProzeB kontrol- 
. lers.empfangen und gespeichert. Dies macht es seinerseits 
moglich, daB der zentralisierte ProzeBkontroller die Steue- 

50 rung uriterschiedlicher analoger und digitaler Bereichsvor- 
richtungen integriert, die die momentane Konflguration und 
Zustand von ' Abschnitten des ProzeBregelnetzwerks dar- 
stellt, in welchem diese Vorrichtungen gelegen sind, um An- 
derungen in der ProzeBregelnetzwerkkonfiguration in bezug 

55 auf diese Vorrichtungen usw. vorzunehmen. Wenn jedoch 
ein dezentralisiertes Steuerschema, wie beispielsweise das 
Fieldbus-Steuerschema in einem Teil des Prozesses verwen- 
det wird, braucht der zentralisierte ProzeBkontroller keinen 
direkten Zugriff mehr auf all die laufenden Informationen zu 

60 haben, die durch die ProzeBsteuervorrichtungen verwendet 
werden oder diesen zugeordnet sind, die der dezentralisier- 
ten Steuerung unterworfen sind. Tatsachlich sind einige de- 
zentralisierte ProzeBsteuerprotokolle, wie beispielsweise 
das Fieldbus-Protokoll, spezifisch so ausgelegt, daB es nicht 

65 erforderlich ist, Informationen zu einem zentralisierten Pro- 
zeBkontroller auf einer regularen Grundlage zu senden. 
Diese Tatsache macht es fur den zentralisierten ProzeBkon- 
troller schwierig, die Steuerung von analogen oder anderen 
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digitalen Bereichsvorrichtungen mit den Bereichsvorrich- 
tungen zu integrieren, die der dezentralisierten Steuerung 
unterworfen sind. Es macht es auch fur den zentralisierten' 
ProzeBkontroller schwierig, den laufenden oder momenta- 
nen Zustand der Vorrichtungen als Modeil nachzubilden 
oder darzustellen, die der dezentralisierten Steuerung unter- 
worfen sind, oder dies innerhalb eines dezentralisierten Ab- 
schnitts des ProzeBregelnetzwerks durchzufiihren. 

Tatsachlich mussen fur den zentralisierten ProzeBkontrol- 
ler, der die Informationen von dem dezentralisierten Steuer- 
abschnittdes ProzeBregelnetzwerks empfangt, die Bereichs- 
vorrichtungen (oder Funktionsblocke) innerhalb dieses Ab- 
schnitts des Prozesses spezifisch konfiguriert sein, um Infor- 
mationen direkt zu dem zentralisierten ProzeBkontroller zu 
senden (was bedeutet, daB der zentralisierte ProzeBkontrol- 
ler all diese Informationen empfangen und handhaben muB, 
wobei der groBte Teil derselben fur die Betriebsweise des 
zentralisierten ProzeBkontrollers nicht erforderlich ist). Al- 
.ternativ muB der zentralisierte ProzeBkontroller aktiv anfra- 
gen, um die von ihm. benotigten Informationen zu empfan- 
gen. Da solch einer Anfrage keine hohere Prioritat in bei- 
spielsweise dem Fieldbus-Protokoll gegeben wird, und zwar 
zu der Zeit, in der der zentralisierte ProzeBkontroller die an- 
gefragten Informationen empfangt, konnen diese Informa- 
tion veraltet sein. Es ist ferner fur den zentralisierten Pro- 
zeBkontroller schwierig, wenn nicfit unmoglich, Daten an- 
zufragen und zu empfangen, die zu einer spezifizierten Zeit 
oder Zeitpuhkt aktiv oder momentan vorhanden sind. Statt 
dessen empfangt der zentralisierte ProzeBkontroller ledig- 
lich die Daten zu dem Zeitpunkt, zu welchem die Anfrage 
die Bereichsvorrichtung erreicht, Daruber hinaus ist die 
Kommunikation zwischen dem zentralisierten ProzeBkon- 
troller und den Bereichsvorrichtungen innerhalb des dezen- 
tralisierten Abschnitts des Prozesses hoch spezialisiert und 
erfordert ein betrachtliches Wissen iiber das dezentralisierte 
Steuerprotokoll, was es fur den Konstrukteur oder Entwick- 
ler der zentralisierten ProzeBsteuerroutine schwierig macht, 
diese Kommunikation auf einer gewunschten Basis zu im- 
plementieren. 

Die vorliegende Erfindung zielt auf die Verwendung von 
Schattenfunktionsblocken ab, um in einem zentralisierten 
ProzeBkontroller die Steuerung der Funktionsblocke, die in 
dem zentralisierten Kontroller vorherrschen, mit solchen zu 
integrieren, die in einer externen Vorrichtung vorherrschen, 
wie beispielsweise einer Bereichsvorrichtung. Die vorlie- 
gende Erfindung kann auch dafiir verwendet werden, einem 
Kontroller die Moglichkeit zu geben, Vorrichtungen oder 
Funktionsblocke zu steuern oder mit diesen zu kommunizie- 
ren, die in einem Kommunikationsnetzwerk gelegen sind 
oder die ein Kommunikationsprotokoll verwenden, welches 
von demjenigen verschieden ist, welches der Kontroller ver- 
wendet Speziell wird ein Schattenfunktionsblock in dem 
zentralisierten Kontroller erstellt oder eingerichtet, um die 
Daten, die einem externen Funktionsblock zugeordnet sind, 
der in einer externen Vorrichtung, wie beispielsweise einer 
Bereichsvorrichtung, gelegen ist, zu spiegelri, und zwar in 
Eiriklang mit einem dezentralisierten Steuer- und Kommu- 
nikationsprotokoll. Die ■ Steuerroutine des ■ zentrahsierten 
Kontrollers kommuniziert mit dem externen Funktionsblock 
iiber den Schattenfunktionsblock, so als ob der externe 
Funktionsblock durch den zentralisierten Kontroller imple- 
mentiert ware. Der Schattenfunktionsblock erhalt automa- 
. tisch die momentanen Informationen, die dem externen 
Funktionsblock zugeordnet sind, und sendet Befehle zu dem 
externen Funktionsblock unter Verwendung des Protokolls, 
welches dem externen (z. B. dezentralisierten) Steuerproto- 
koll zugeordnet ist. Im Falle eines Fieldbus-Protokolls. wird 
diese Kommunikation unter Verwendung von sowohl syn- 



10 230 A 1 

.4 

chronen als auch asynchronen Kommunikationen erreicht. 
Jedoch kommuniziert der Schattenfunktionsblock mit ande- 
ren Funktionsblocken innerhalb des zentralisierten Kontrol- 
lers so, als ob der externe Funktionsblock vollstandig durch 

■ 5 , den zentralisierten Kontroller implementiert ware. 

Unter Verwendung des Schattenfunktionsblockes der vor- 
liegenden Erfindung kann die zentralisierte ProzeBsteuer- 
routine auf den neuesten Stand gebrachte Informationen um 
den tatsachlichen Funktionsblock herum in einer Realzeit 

10 oder nahezu auf Realzeitbasis empfangen, da diese Informa- 
tionen in dem Schattenfunktionsblock gespiegelt werden, 
der immer fur die zentralisierte ProzeBsteuerroutine zugang- 
lich ist. In ahnlicher Weise kann die zentralisierte ProzeB- 
steuerroutine Befehle zu dem tatsachlichen Funktionsblock 

15 dadurch senden, indem sie einen Befehl zu dem Schatten- 
funktionsblock ungeachtet des Typs oder der Lag'e der Vor- 
richtung sendet, in welcher der tatsachliche Funktionsblock 
gelegen ist. Der Schattenfunktionsblock setzt dann diesen 
Befehl unmittelbar in Verbindung zu dem tatsachlichen 

20 Funktionsblock unter Verwendung geeigneter Kommunika- 
tionsbefehle, die dem dezentralisierten ProzeBsteuerproto- 
koll zugeordnet sind. Auf diese Weise braucht die zentrali- 
sierte ProzeBsteuerroutine keine signifikante Datenbasis- 
steuerung in bezug auf die Bereichsvorrichtungen durchzu- 

25 fuhren, und zwar innerhalb des dezentralisierten Steuerab- 
schnitts des Prozesses, da die Informationen, die sie fur die 
Bereichsvorrichtungen innerhalb des dezentralisierten Ab- 
schnitts des ProzeBregelnetzwerks, in dem Schattenfunkti- 
onsblock bzw. den Schattenfunktionsblocken gelegen sind. 

30 In ahnlicher Weise braucht die zentralisierte ProzeBsteuer- 
routine nicht spezifische programmiert zu werden, um mit 
den komplexen und fordernden Aufgaben der Kommunika- 
tion in dem dezentralisierten ProzeB steuerprotokoll fertig zu 
• werden, da diese Kommunikation automatisch durch den 

35 Schattenfunktionsblock durchgefuhrt wird. 

GemaB einem Aspekt der vorliegenden Erfindung ist ein 
Interface oder Schattenfunktionsblock dafur ausgebildet, 
um in einem ProzeBkontroller verwendet zu werden, der 
kommunikativ mit einer externen Vorrichtung iiber ein 

40 Kommunikationsnetzwerk gekoppelt ist, um dem ProzeB- 
kontroller die Moglichkeit zu geben, eine Steuerroutine un- 
ter Verwendung von sowohl dem internen Funktionsblock, 
der in dem ProzeBkontroller vorherrscht, als auch eines ex- 
ternen Funktionsblockes, der innerhalb der externen Vor- 

45 richtung vorhanden ist, zu implementieren. Das Interface 
oder der Schattenfunktionsblock gemaB diesem Aspekt der 
Erfindung enthalt einen Kommunikationsport mit einem 
Eingang, der mit dem externen Funktionsblock uber das 
Kommunikationsnetzwerk kommuniziert, um "dadurch Da- 

50 ten zu empfangen, die zum externen Funktionsblock geho- 
ren, und enthalt einen Speicher, der die empfangen en Daten, 
die zu dem extemen Funktionsblock gehoren, gemaB einem 
Konfigurationsprotokoll des internen Funktionsblockes 
speichert. Wenn es erwunscht ist, kann der Interface-Funk- 

55 tionsblock auch einen Ausgang aufweisen, der die gespei- 
cherten externen Funktionsblockdaten zu dem internen 
, Funktionsblock liefert, und zwar unter Verwendung .des 
Konfigurationsprotokolls des internen Funktionsblocks. In 
ahnlicher Weise kann der Kommunikationsport- des Inter- 

60 face-Funktionsb locks einen Ausgang enthalten, der Daten 
(wie beispielsweise verkettete Daten oder Befehle) zu dem 
externen Funktionsblock sendet, und zwar unter Verwen- 
dung eines Kommunikationsprotokolls, welches dem exter- 
nen Funktionsblock zugeordnet ist. 

65 In bevorzugter Weise empfangt der Kommunikationsport 
des Interface-Funktionsblocks die Daten, die zu dem exter- 
nen Funktionsblock gehoren, unabhangig von der Operation 
der internen Funktionsblocke. In ahnlicher Weise kommunir 
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ziert bei einer Ausfuhrungsform der externe Funktionsblock 
uber das Kommunikationsnetzwerk unter Verwendung eines 
ersten KommunikationsprotokoUs, welches verschieden ist 
vori einem zweiten Konimunikationsprotokoll, welches dem 
internen Funktionsblock zugeordnet ist, und in diesem Fall 
kommuniziert der Kommunikationsport mit dem externen 
Funktionsblock unter Verwendung des ersten Kommunika- 
tionsprotokolls und der Ausgang des Interface-Funktions- 
blocks kommuniziert mit dem internen Funktionsblock ge- 
maB dem zweiten Kommunikationsprotokoll. 

Wenn es gewiinscht wird, kann das erste Kommunikati- 
onsprotokoll, welches dem externen Funktionsblock zuge- 
ordnet ist, ein Fieldbus-Kommunikationsprotokoll sein. In 
diesem Fall kann der Kommunikationsport eine Interface- 
vorrichtung (wie beispielsweise eine Interfacekarte) ver- 
wenden, die dafiir konfiguriert ist, um mit der externen Vor- 
richtung unter Verwendung des Fieldbus-Kommunikations- 
protokolls zu kommunizieren, um dadurch eine Kommuni- 
kation mit dem externen Funktionsblock vorzunehmen. per 
Kommunikationsport kann beispielsweise mit dem externen 
Funktionsblock unter Verwendung synchroner Kommunika- 
tionen kommunizieren, wie beispielsweise die Herausgeber- 
/Teilnehmerbeziehungen des Fieldbus-Kommunikations- 
protokolls und/oder kann asynchrone Kommunikationen 
verwenden, wie z. B. die Betrachtungsobjekte in dem Field- 
bus-Kommunikationsprotokoll. Allgemeiner kann die ex- 
terne Vorrichtung unter Verwendung eines Vorrichtungs- 
Kommunikationsprotokolls kommunizieren, welches die 
Kommunikation der logisch verketteten Pakete an Daten un- 
ter Verwendung von standardisierten Kommunikationsrufen 
unterstiitzt, wie beispielsweise die Betrachtungsobjekte und 
die Betrachtungswarnungen des Fieldbus-Kommunikati- 
onsprotokolls, und es kann der Kommunikationsport mit 
dem externen Funktionsblock unter Verwendung der stan- 
dardisierten Kommunikationsrufe kommunizieren. In ahnli- 
cher Weise kann der Kommunikationsport Alarmanzeigen 
von dem externen Funktionsblock empfangen und kann 
diese Alarmanzeigen in dem Speicher fur die Verwendung 
durch den Kontroller speicherm 

GemaB einem anderen Aspekt der vorliegenden Erfin- 
dung enthalt ein Kontroller, der dafur geeignet ist, um kom- 
munikativ an eine Vielzahl von Bereichsvorrichtungen ge- 
koppelt zu werden, einen Speicher und eine Steuerroutine 
enthalten, die in dem Speicher abgespeichert ist und die 
durch den Prozessor implementiert ist, um die vielzahl der 
Bereichsvorrichtungen zu steuern. Die Steuerroutine enthalt 
eine Vielzahl von miteinander verbundenen internen Funk- 
tionsblocken, die unter Verwendung eines Kontrollerproto- 
kolls. konfiguriert sind, so daB sie durch den Kontroller im- 
plementiert werden, und kann einen Interface-Funktions- 
block enthalten, der mit einem der miteinander verbundenen 
internen Funktionsblocken kommuniziert, unter Verwen- 
dung des Kontrollerprotokolls und der mit einem externen 
Funktionsblock kommuniziert, der in einer externen Be- 
reichsvorrichtung vorhanden ist, und zwar unter Verwen- 
dung eines Bereichsvorrichtungs-Kommunikationsproto- 
kolls. Der Interface-Funktionsblock speichert Daten, die zu 
dem externen Funktionsblock gehoren und von dem exter- 
nen Funktionsblock fur die Verwendung durch die Steuer- 
routine empfangen werden. 

■ GemaB einem weiteren Aspekt der vorliegenden Erfin- 
dung speichert ein Verfahren zum Implementieren einer 
Steuerroutine innerhalb eines ProzeBkontrollers, innerhalb 
des Kontrollers eine Vielzahl von miteinander verbundenen 
internen Funktionsblocken, die gemaB einem Kontrollerpro- 
tokoll konfiguriert sind, um einen Teil der Kontrollerroutine 
zu implementieren. Das Verfahren erzeugt auch innerhalb 
des Kontrollers einen Interface-Funktionsblock, der gemaB 



dem Kontrollerprotdkoll konfiguriert. ist, der jedoch mit ei- 
pern externen Funktionsblock kommuniziert, der in einer 
externen Bereichsvorrichtung gelegen ist, und zwar unter 
Verwendung eines Vorrichtungs-Kommunikationsproto- 

5^ kolls, welches der externen Vorrichtung zugeordnet ist. Das 
Yerfahren erzeugt dann eine Steuerroutine, welche die .Viel- 
zahl der miteinander verbundenen internen Funktionsblocke 
und den Interface-Funktionsblock verwendet, um den Pro- 
zeB zu steuern oder zu regeln und wahrend der Implementie- 

10 rung der Steuerroutine werden Daten gespeichert, die dem 
externen Funktionsblock zugeordnet sind und von diesem 
empfangen werden, und zwar in dem Interface-Funktions- 
block fur die Verwendung durch die Steuerroutine, so als ob 
der externe Funktionsblock durch den Kontroller als einer 

15 der internen Funktionsblocke implementiert ware. 

Das Verfahren kann einem Anwender auch erlauben, die 
Steuerroutine dadurch zu konfigurieren, indem jeder eine 
Anzahi von Funktionsblocken, die in der Steuerroutine ver- 
wendet werden sollen, spezifiziert wird, die Verbindungen 

20 zwischen den spezifizierten Funktionsblocken, die in der 
Steuerroutine zu verwenden sind, identifiziert werden und 
die S telle oder Ort eines bestimmten spezifizierten Funk- 
tionsblockes spezifiziert wird, und zwar als ein interner 
Funktionsblock, der in dem Kontroller implementiert ist, 

25 oder als ein externen. Funktionsblock, der durch eine Be- 
reichsvorrichtung implementiert ist. In dem Fall, bei wel- 
chem ein Funktionsblock in einer externen Vorrichtung zu 
implementieren ist, enthalt das Verfahren den Schritt gemaB 
einer Auswahl einer externen Vorrichtung aus einer Liste 

30 oder einem Satz von Vorrichtungen, die in dem System ver- 
bunden oder angeschlossen sind. , 

Fig. 1 ist ein schematisches Blockschaltbild eines bei- 
spielhaften ProzeBregelnetzwerks, welches zentralisierte 
und dezentralisierte ProzeBsteuerabschnitte darin enthalt; 

35 Fig; 2 ist ein schematisches Blockschaltbild von drei 
Standardfunktionsblocken, die einer oder mehreren Field- 
bus-Bereichs vorrichtungen zugeordnet sind; 

Fig. 3 ist ein Zeitsteuerschema fur einen Makrozyklus ei- 
nes Segments eines Fieldbus-Busses, der innerhalb des Pro- 

40 zeBregelnetzwerks von Fig. 1 gelegen ist; 

Fig. 4 ist ein schematisches Blockschaltbild, welches die 
Verbindung eines Schattenfunktionsblockes mit anderen 
Funktionsblocken herausgreift, die einer zentralisierten Pro- 
zeB steuerroutine zugeordnet sind und innerhalb eines zen- 

45 tralisierten ProzeBkontrollers gelegen sind; 

Fig. 5 ist ein Blockdiagramm eines Teiles eines ProzeBre- 
gelsystems unter Verwendung des Schattenfunktionsblockes 
der vorliegenden Erfindung; 

Fig. 6 ist ein RuBdiagramm, welches die Installation ei- 

50 nes Steuermoduls innerhalb des Kontrollers von Fig. 1 ver- 
anschaulicht; 

Fig. 7 ist ein FluBdiagramm, welches die Installation ei- 
nes aktiven Verbindungsgliedplans in dem Fieldbus-Ab- 
schnitt des .ProzeBregelnetzwerks von Fig. 1 veranschau- 
55 licht; 

Fig. 8 ist ein RuBdiagramm, welches die Installation von 
Veroffentlicher-Bindegliedern in dem Fieldbus-Abschnitt 
des ProzeBregelnetzwerks von Fig. 1 veranschauHcht; 

Fig. 9 ist ein RuBdiagramm, welches'die Installation ei- 
60 ner Vorrichtungskonfiguration in einer Vorrichtung inner- 
halb des Fieldbus-Abschnitts des ProzeBregelnetzwerks von 
Fig. 1 veranschaulicht; 

Fig. 10 ist ein FluBdiagramm, welches die Installation ei- 
nes Funktionsblockes innerhalb einer Vorrichtung in dem 
65 Fieldbus-Abschnitt des ProzeBregelnetzwerks von Fig. 1 
veranschaulicht; 

Fig. 11 ist ein FluBdiagramm, welches die Betriebsweise 
des Funktionsblocks und darauf bezogener Komponenten 



DE 199 40 230 A 1 



8 



wahrend des Betriebs eines zentralisierten Steuermoduls 
veranschaulicht, und zwar unter Verwendung des.Schatten- 
funktionsblockes; und 

Fig. 12 ist ein RuBdiagramm, welches die Kommunika- 
tion von Daten und von Schreibanfragen von einem Block in 5 
einem zentralisierten Kontroller oder einem Anwender zu 
einem externen Funktionsblock in einer Bereichsvprrich- 
tung unter Verwendung des Schattenfunktionsblockes der 
Erfindung veranschaulicht. 

GemaB Fig. 1 ist ein ProzeBregelnetzwerk 10 in Block- 10 
diagrammform veranschaulicht. Das ProzeBregelnetzwerk 
10 enthalt einen zentralisierten PrbzeBkontroller 12, der eine 
ProzeBsteuerroutine, die in diesem gespeichert ist, imple- 
mentieren kann. Der Kontroller 12 kann, um hier lediglich 
ein Beispiel zu nennen, der DeltaV (eingetrage'ne Marke) 15 
Kontroller sein, der durch Fisher-Rosemoiint Systems ver- 
trieben wird, und kann an verschiedene Workstations, wie 
beispieisweise Personalcomputer (PCs)' 14 uber einen Hub 
16 und Ethernet- Verbindungen 18 verbunden sein. In dieser 
^Configuration konnen die PCs 14 durch eine oder mehrere 20 
.Bedienungspersonen oder Anwender verwendet werden, um 
mit dem ProzeBkontroller 18 eine Kommunikation herzu- 
stellen, um dadurch Informationen zu erhalten, die das Pro- 
zeBregelnetzwerk 10 betrefFen, um den Status des ProzeBre- 
gelnetzwerks 10 zu uberblicken oder zu andern, um Infor- 25 
mationen zu erhalten, die die einzelnen Bereichsvorrichtun- 
gen innerhalb des ProzeBregelnetzwerks 10 betreffen usw. 
Wenn der Kontroller 12 aus einem Delta V-Kontroller be- 
steht, kann er einen graphischen Ausschnitt der ProzeB- 
steuer- oder -regelroutine innerhalb des Kontrollers 12 zu 30 
dem Anwender liefern, und zwar uber einen der PCs 14, wo- 
bei die Funktionsblocke oder Steuerblocke innerhalb der 
ProzeBsteuerroutine veranschaulicht werden und auch die 
Art, in welcher diese Funktionsblocke miteinander verkettet 
sind, um die Steuerung oder Regelung eines Prozesses zu 35 
bewirken. Der Anwender hat die Moglichkeit, die ProzeB- 
steuer- oder -regelroutine zu andern, und zwar innerhalb des • 
zentralisierten ProzeBreglers 12, indem er den graphischen 
Ausschnitt der Funktionsblocke innerhalb der Steuer- oder 
Regelroutine manipuliert, um Funktionsblocke von dieser 40 
Steuerroutine . wegzulassen oder zu dieser hinzuzufugen 
und/oder den Weg zu andern, in Welchem die Funktions- 
blocke, die der Steuerroutine zugeordnet sind, verkettet 
sind, das heiBt den Weg oder die Art, in welcher sie verbun- 
den sind. 45 

Wie in Fig. 1 dargestellt ist, ist der zentralisierte Kontrol- 
ler 12 mit zahlreichen Bereichsvorrichtungen (field devices) 
verbunden, die uber einen ProzeB hinweg verteilt gelegen 
sind (allgemein durch das Bezugszeichen 19 angezeigt> . ; 
Der zentralisierte Kontroller 12 kanri uber irgendwelche 50 
Standardtypen I/O-Karten 20 und 22 mit den Bereichsvor- 
richtungen 26, 28, 30, 32, 34 und 36 kommunizieren, die der 
zentralisierten Steuerung von dem Kontroller 12 unterwor- 
fen sind. Die I/O-Karte 20 kann beispieisweise eine.analoge 
I/O-Karte sein, die den Kontroller 12 mit analogen Be- 55 
reichs vorrichtungen 24 und 26 verbindet, die uber 4-20- 
mA-Busse 38 kommunizieren. In ahnlicher Weise kann die 
I/O-Karte 22 eine digitale oder kombinierte digitale und 
analoge I/O-Karte sein, die mit digitalen oder gemischten 
digitalen und analogen Bereichsvorrichtungen in irgendei- 60 
nem gewunschten Format kommuniziert, inklusive bei- 
spieisweise dem 4-20-mArAnalogformat oder irgendeinem 
bekannten oder standardisierten Digitalformat. Natiirlich 
konnen.die Bereichsvorrichtungen 26, 28, 30, 32, 34 und 36 
von irgendeinem gewunschten Typ von Bereichsvorrichtun- 65 
gen bestehen, beispieisweise aus Sendern, Sensoren, Ventil- 
stellgliedern, Ventilsteuervorrichtungen usw. Es sei in Ver- 
bindung mit dem Beispiel des in Fig. 1 veranschaulichten 



ProzeBregelnetzwerks 10 darauf hingewiesen, daB die Be- 
reichsvorrichtungen 26-36 Abschnitten des Prozesses 19 
zugeordnet sind, die einer zentralisierten Steuerung durch 
die Steuerroutine innerhalb des Kontrollers 12 unterworfen 
sind. 

Der Kontroller 12 ist ebenfalls kommunikativ mit einer 
Interfacekarte 40 verbunden, die ihrerseits mit (oder Teil ist 

1 von) einem externen ProzeBregelnetzwerk, in welchem die 
ProzeBregelung in einer verteilten Weise durchgefuhrt wird, 
oder welcher Vorrichtungen enthalt, die Funktionsblocke 
haben, die unter Verwendung eines Kommunikation sproto- 
kolls kommunizieren, welches verschieden ist von demjeni- 
gen, welches innerhalb des Kontrollers 12 verwendet wird. 
Bei der in Fig. 1 veranschaulichten Ausfuhrurtgsform ent- 
halt der dezentralisierte ProzeBsteuerabschnitt des Prozesses 
19 die Interfacekarte 40, einen Bus 42 und zahlreiche Be- 
reichsvorrichtungen 43, 44, 46, 48 und 50, die an den Bus 42 
angeschaltet sind. Das verteilte ProzeBregelnetzwerk von 
Fig. 1 kann beispieisweise ein Fieldbus-Netzwerk sein, wel- 
ches das Fieldbus-Kommunikationsprotokoll verwendet. 
Wie.im folgenden noch mehr in Einzelheiten erlautert wer- 
den wird, kann die Interfacekarte 40 eine aktive Verbin- 
dungsglied-Ablauf steuerung sein, die dem Fieldbus-Kom- 
munikationsprotokoll zugeordnet ist. 

Die zentralisierte ProzeBsteuerroutine, die innerhalb des 

. Kontrollers 12 gelegen ist, empfangt EingangsgroBen von 
den Bereichsvorrichtungen 26-36 und moglicherweise 
43-50, fuhrt Berechnungen und andere Aktivitaten durch, 
die mit der Steuerroutine verbunden sind, und sendet dann 
Befehle zu den Bereichsvorrichtungen uber die I/O-Karten 

.20 und 22 und die Interfacekarte 40, um irgendeine ge- 
wiinschte Steuerung oder Regelung des Prozesses 19 zu im- 
plementieren. Es sei jedoch darauf hingewiesen, daB der de- 
zentralisierte ProzeBsteuer- oder -regelabschnitt des ProzeB- 
regelnetzwerks 10 (das heiBt derjenige, der dem Bus 42 in 
Fig. 1 zugeordnet ist) seine eigene ProzeBsteuerroutine in 
einer dezentralisierten Weise implementieren kann, wie dies 
hier noch beschrieben wird, und zwar in Verbindung mit der 
Steuerung, die durch den Kontroller 12 ausgefiihrt wird. 
Wahrend somit der Kontroller 12 mit einer Steuerung ge- 
koppelt sein kann und eine gewisse Steuerung uber die Vor- 
richtungen 43-50, die an deri Bus 42 angeschlossen sind, 
ausfiihren 1 kann, konnen diese Vorrichtungen auch Steuer- 
funktionen implementieren oder Funktionsblocke, die mit 
der Steuerung verbunden sind, welche durch den Kontroller. 
12 implementiert wird, die jedoch statt dessen uber die Vor- 
richtungen, die an den Bus 42 angeschlossen sind, verteilt 
sind. 

' Wahrend bei der bevorzugten Ausftihrungsform der de- 
zentralisierte Abschnitt des ProzeBregelnetzwerks 10 das 
Fieldbus-Kommuhikations- und -Steuerprotdkoll verwen- 
det, kann irgendein anderes oder gewiinschtes Protokoll 
ebenso verwendet werden, inklusive den Protokollen, die in 
der Zukunft entwickelt werden. Ferner kann der Schatten- 
funktionsblock, der hier offenbart ist, dazu verwendet wer- 
den, um eine Kommunikation zwischen irgendwelchen zwei 
unterschiedlichen Steuer- oder Kommunikationsprotokollen 
durchzuftihren, und es liegt keineBeschrankung auf die Ver- 
wendung zwischen einer zentralisierten Steuerroutine und 
einem dezentralisierten Steuer- oder Regelnetzwerk, wie 
beispieisweise auf eines, welches das Fieldbus-Protokoll 
verwendet, vor. Es kann beispieisweise zwischen zwei un- 
terschiedlichen zentralisierten Steuerroutinen oder Proto- 
kollen, die Steuerblocke ehthalten, verwendet werden. Mit 
anderen Worten ist der hier beschriebenen Schattenfunkti- 
onsblock nicht darauf beschrankt, mit Funktionsblocken in 
dem Fieldbus-Protokoll verwendet zu werden oder sogar 
mit einem Protokoll, welches einer- dezentralisierten Steuer- 
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routine zugeordnet ist, sondern kann auch dazu verwendet 
werden, einen Kontroller (oder andere Vorrichtung) dazu zu 
befahigen, mit irgendeiner anderen externen Vorrichtung zu 
kommunizieren, die irgendeinen unterschiedlichen Typ ei- 
nes Kommunikationsprotokolls verwendet. 5 

Bevor Einzelheiten des Schattenfunktionsblockes der 
Vorliegenden Erfindung erlautert werden und die Art, in 
welcher der zentralisierten ProzeBkontroller 12 solch einen 
Schattenfunktionsblock verwendet, um eine Steuerung in ei- 
nem ProzeBregelnetzwerk zu implementieren, folgt eine all- 10 
gemeine Beschreibung des Fieldbus-Protokolls, der Be- 
reichsvorrichtungen, die gemaB diesem Protokoll konfigu- 
riert sind, und die Art, in welcher die Kommunikation in 
dem Abschnitt des ProzeBregelnetzwerks 10 erfolgt, der das 
Fieldbus-Protokoll verwendet. Es sei darauf hingewiesen, 15 
daB, obwohl des Fieldbus-Protokoll bereits ein relativ neues 
gesamtdigitales Kommunikationsprotokoll ist, welches fur 
die.Verwendung irl einem ProzeBregelnetzwerk entwickelt 
wurde, dieses Protokoll auf dem Gebiet bekannt ist und in 
Einzelheiten in vielerlei Artikeln, Broschiiren und Beschrei- 20 
bungen beschrieben ist, die veroffentlicht, verteilt und von 
der Fieldbus Foundation unter anderem verfugbar sind, ei- 
ner nicht auf Profit basierenden Organisation, die ihren Sitz 
in Austin, Texas, hat. Speziell ist das Fieldbus-Protokoll und 
die Art der Kommunikation mit und die Art der Speicherung 25 
von Daten in Vorrichtungen, die das Fieldbus-Protokoll ver- 
wenden, in Einzelheiten in den Bedienungsanleitungen be- 
schrieben, mit dem Titel "Communications Technical Speci- 
fication" und "User Layer Technical Specification" von der 
Fieldbus Foundation. 30 

Allgemein gesagt, besteht das Fieldbus-Protokoll 1 aus ei- 
nein insgesamt digitalen, seriellen Zweiwege- Kommunika- 
tionsprotokoll, welches eine standardisierte physikalische 
Schnittstelle fur eine Zweidrahtschleife oder Bus schafft, die 
"Feld'-Ausriistungen, wie beispielsweise Sensoren, Stell- 35 
glieder, Kontroller, Ventiie usw., miteinander verbindet, die 
in einer MeBgerateausriistung oder einer ProzeBsteuer- oder 
-regelumgebung gelegen sind, beispielsweise in einer Fa- 
brik oder Ahlage. Das Fieldbus-Protokoll betrifft im Prinzip 
ein ortliches Bereichsnetzwerk fur BereichsmeBgerate (Be- 40 
reichs vorrichtungen) innerhalb eines Prozesses, welches 
diese Bereichsvorrichtungen dazu befahigt, Steuerfunktio- 
nen an Stellen auszufuhren, die iiber eine ProzeBeinrichtung 
hinweg verteilt sind, und mit einer anderen zu kommunizie- 
ren, vor und nach der Ausfuhrung dieser Steuerfunktionen, 45 
um eine Gesamtsteuer- oder -regelstrategie zu realisieren. 
Da das Fieldbus-Protokoll es deh Steuerfunktionen ermog- 
licht, iiber ein ProzeBregelnetzwerk hinweg verteilt zu sein, 
reduziert es die Arbeitslast des zentralisierten ProzeBkon- 
trollers fur diese Bereichsvorrichtungen oder fur die Berei- 50 
che des Prozesses. 

Ein ProzeBsteuer- oder -regelnetzwerk, welches das 
Fieldbus-Protokoll verwendet, kann einen Host enthalten, 
der mit eirier Anzahl von anderen Vorrichtungen verbunden 
ist, wie beispielsweise logischen Programmkontrollern, an- 55 
deren Hostvorrichtungen und Bereichsvorrichtungen (field 
devices) iiber eine Zweidraht-Fieldbus-Schleife oder -Bus, 
wie beispielsweise den Bus 42 von Fig. 1 . Der Fieldbus-Bus 
kann unterschiedliche Abschnitte oder Segmente enthalten, 
die durch Briickenvorrichtungen getrennt sind, wobei jeder 60 
Abschnitt des Busses einen untergeordneten Satz der Vor- 
richtungen verbindet, die an den Bus angebracht sind, um 
Kommunikationen zwischen den Vorrichtungen in einer 
Weise zu ermoglichen, wie sie im folgenden beschrieben 
wird. In typischer Weise ist eine Konfiguriervorrichtung in 65 
einer der. Vorrichtungen gelegen, wie beispielsweise einem 
Host, und ist fur die Einrichtung oder Konfigurierung jeder 
der Vorrichtungen verantwortlich (die "Smart" -Vorrichtun- 



gen insofern sind, als sie jeweils einen Mikroprozessor ent- 
halten, der eine Kommunikation durchfuhren kann und in 
einigen Fallen Steuerfunktionen durchfuhren kann), der 
aber ebenso erkennen kann, wenn neue Bereichsvorrichtun- 
gen an den Fieldbus-Bus angeschlossen werden, wenn die 
Bereichsvorrichtungen von dem Bus entfernt werden, der 
Daten erkennen kann, die durch die Bereichsvorrichtungen, 
welche an den Bus angeschlossen sind, erzeugt werden, und 
der eine Kopplung mit einer oder mit mehreren Anwender- 
terminals bewirkt, die in dem Host oder irgendeiner anderen 
Vorrichtung gelegen sein ktinnen, welche in irgendeiner 
Weise an den Host angeschlossen sind. 

Der Fieldbus-Bus unterstutzt oder erlaubt zweierlei: eine 
rein digitale Kommunikation und er kann auch ein Strom- 
versorgurigssighal zu irgendeiner oder zu all den Vorrichtun- 
gen, die an ihn angeschlossen sind, ubertragen, wie bei-' 
spiels weise an die Bereichsvorrichtungen. Alternativ kann 
irgendeine oder konnen alle Fieldbus- Vorrichtungen ihre ei- 
gene Strom versorgung besitzen oder konnen iiber separate 
Leitungen mit externen Stromversorgungen verbunden sein. 
Das Fieldbus-Protokoll erlaubt es vielen Vorrichtungen/Ver- 
drahtungstopologien, inklusive Vielfachvorrichtungen, . an 
das gleiche Paar von Drahten oder Leitungen angeschlossen 
zu werden, erlaubt Punkt-zu-Punkt-Verbindungen, in wel- 
chen jede Vorrichtung an einen Kontroller oder einen Host 
iiber ein getrenntes Zweidrahtpaar angeschlossen ist (ahn- 
lich den typischen 4-20 mA Analogsystemen) und Baum- 
oder "spur"-Verbindungen realisiert sirid, in denen jede Vor- 
richtung mit einem gemeinsamen Punkt in einem Zweilei- 
tungsbus verbunden ist, der beispielsweise aus einem Ka- 
belkasten oder Verzweigungsstiick oder einem AbschluBbe-, 
reich in einer der Bereichsvorrichtungen innerhalb eines 
ProzeBsteuer- oder ^regelnetzwerks bestehen kann. 

Es konnen Daten iiber die Bussegmente in irgendeiner ei- 
ner Anzahl von unterschiedlichen Kommunikationsbauraten 
oder Geschwindigkeiten gemaB dem Fieldbus-Protokoll ge- 
sendet werden. Beispielsweise schafft das Fieldbus-Proto- 
koll eine 31,25-Kbit/s-Kommunikationsrate (HI) oder eine 
1,0-Mbits- und/oder eine 2,5-Mbit/s-(H2)-Kommunikati- 
onsrate, die in typischer Weise fur eine fortschrittHche Pro- 
zeBsteuerung oder -regelung, Ferneingabe-/-ausgabe und fiir 
Hochgeschwindigkeits-Fabrikautomatisationsanwendurigen 
angewendet werden. In gleicher Weise konnen iiber den 
Fieldbus-Bus Daten unter Verwendung einer Spannungs- 
mode-Signalgebung oder einer Strommode-Signalgebung 
ubertragen werden. Die maximale Lange von irgendeinem 
Fieldbus-Bus oder -Segment ist nicht strikt begrenzt, son- 
dern wird statt dessen durch die Kommunikationsrate, den 
Kabeltyp, die LeitungsgroBe, Busleistungsoptionen usw. 
festgelegt. 

Das Fieldbus-Protokoll klassifiziert die Vorrichtungen, 
die an den Bus angeschlossen werden konnen, in drei pri- 
mare Kategorien, namlich die Basis vorrichtungen, die Ver- 
bindungsmastervorrichtungen und die Briickenvorrichtun- 
gen. Die Basisvorrichtungen konnen kommunizieren, das 
heiBt Kommunikationssignale auf den Bus senden oder von 
diesem empfangen, sind jedoch nicht dazu befahigt, die Rei- 
henfolge oder Zeitsteuerung der Kommunikation zu steuern, 
die auf dem Bus auftreten. Die Verbindungsmastervorrich- 
tungen bestehen aus Vorrichtungen, die iiber dem Bus kom- 
munizieren und die Fahigkeit haben, den RuB und die Zeit- 
steuerung der Kommunikationssignale auf den Bus zu steu- 
ern. Die Briickenvorrichtungen bestehen aus Vorrichtungen, 
die dafur konfiguriert sind, um mit einzelneii Segmenten 
oder. Zweigen eines Fieldbus-Busses zu kommunizieren 
oder diese einzelnen Segmente oder Zweige miteinander zu 
verbinden, um ein groBere ProzeBsteuer- oder -regelnetz- 
werk zu erzeugen. Wenn es gewiinscht wird, konnen die 
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Bruckenvorrichtungen zwischen unterschiedlichen Daten- 
geschwindigkeiten und/oder unterschiedlichen Datensigna- 
Hsierungsformaten eine Umwandlung vornehmen, die auf 
deh unterschiedlichen Segrnenten des Busses verwendet 
werden, konnen Signale verstarken, die zwischen den Seg- 
rnenten des Busses wandern, konnen die Signale filtern, die 
zwischen unterschiedlichen Segrnenten des Busses verlau- 
fen, und konnen lediglich solche Signale durchlassen, die 
dafur bestirnmt sind, durch eine Vbrrichtung an einem der 
Bussegmente empfangen zu werden, an welches die Briicke 
gekoppelt ist und/oder konnen andere Aktionen vornehrnen, 
die erforderlich sind, um unterschiedliche Segmente des 
Busses zu verbinden. Die Bruckenvorrichtungen, welche die 
Bussegmente verbinden, die mit unterschiedlichen Ge- 
schwiridigkeiten arbeiten, miissen Verbindungsmasterfahig- 
keiten auf der Seite des Segmentes mit niedrigerer Ge- 
schwindigkeit der Briicke besitzen. 

Jede der Fieldbus-Vorrichtungen besitzt die Fahigkeit, 
iiber den Bus zu kommunizieren, und, was wichtig ist, die 
Fahigkeit unabhangig eine oder mehrere ProzeBsteuerfunk- 
tiorien durchzufuhren unter Verwendung von Daten, die 
durch die Vbrrichtung von dem ProzeB erworben wurden, 
oder von einer unterschiedlichen Vbrrichtung erworben 
wurden, und zwar iiber die Kommunikationssignale auf dem 
Bus. Die Fieldbus-Vorrichtungen besitzen daher die Fahig- 
keit, direkt Abschnitte einer Gesamtsteuer- oder -regelstra- 
tegie zu implementieren, die in der Vergangenheit durch ei- 
nen zentralisierten digitalen Kontroller durchgefiihrt wur- 
• den. Um Steuerfunktionen durchzufuhren, enthalt jede 
Fieldb us- Vbrrichtung einen oder mehrere standardisierte 
"Blbcke", die in einem Mikroprozessor innerhalb der Vor- 
richtung implementiert sind. Speziell enthalt jede Fieldbus- 
Vbrrichtung einen Ressourcenblock, Null- oder Mehrfunkti- 
onsblbcke und Null- oder Mehrwandlerblocke. Diese 
Blbcke werden als Blockobjekte bezeichnet. . 

Ein Ressourcenblock speichert und ubertragt spezifische 
Vorrichtungsdaten, die einige Charakteristika einer Field- 
bus- Vbrrichtung betreffen, inklusive beispielsweise einem 
Vorrichtungstyp,' einer Vorrichtungsrevisionsanzeige und 
Anzeigen daruber, wo andere spezifische Vorrichtungsinfpr- 
mationen innerhalb eines Speichers der Vbrrichtung erhalten 
werden konnen. Wahrend verschiedene Vorrichtungsher- 
steller unterschiedliche Typen der Daten in dem Ressour- 
cenblock einer Bereichsvorrichtung speichern konnen, ent- 
halt jede Bereichsvorrichtung, die mit dem Fieldbus-Proto- 
koll konform ist, einen Ressourcenblock, der einige Daten 
speichert. 

. Ein Funktionsblock definiert und implementiert eine Ein- 
gabefunktioh, eine Ausgabefunktion oder eine Steuerfunk- 
tion, die der Bereichsvorrichtung zugebrdnet ist und es wer- 
den sorriit Funktionsblocke allgemein als Eingabe-, Aus- 
gabe- und Steuerfunktionsblocke bezeichnet. Es konnen je- 
doch andere Kategorien von Funktionsblbcken existieren, 
wie beispielsweise Hybrid-Funktiorisblocke, oder konnen 
auch in der Zukuhft entwickelt werden. Jeder Eingabe- oder 
Ausgabefunktiorisblock erzeugt wenigstens eine ProzeB- 
steuereingangsgroBe (wie beispielsweise eine ProzeBvaria- 
ble aus einer ProzeBmeBvorrichtung) oder eine ProzeBsteu- 
erausgangsgrbBe (wie beispielsweise eine Ventilposition, 
die zu einer Stellvorrichtung gesendet. wird), wahrend jeder 
Steuerfunktionsblock einen Algorithmus verwendet (der in 
seiner Natur geschutzt oder firmeneigen sein kann), um eine 
oder mehrere ProzeBausgangsgroBen aus einer oder aus 
mehreren ProzeBeingangsgrbBen und aus Steuereingangs- 
grbBen zu erzeugen. Beispiele von Standardfunktionsblbk- 
ken umfassen Analogeingangs(Al)-, Analogausgangs(AO)- 
, Vorspann(B)-, Steuerwabl(CS)-, Diskreteingangs(DI)-, 
Diskretausgangs(DO)-, Handlade(ML)-, Proportional/Dif- 



ferential(PD)-, Proportional/Integral/Differential(PDI)-, 
Verhaltnis(RA)- und Signalwahl(SS)-Funktionsblocke," Es 
existieren jedoch andere TVpen von Funktionsblbcken und 
neue TVpen von Funktionsblbcken konnen festgelegt oder 
5 hergestellt werden, um in der Fieldbus-Umgebung zu arbei- 
ten. 

Ein Wandlerblock koppelt die EingangsgrbBen und Aus- 
gangsgrbBen eines Funktionsblockes an die brtlichen Hard- 
warevorrichtungen, wie beispielsweise an Sensoren und 

10 Vorrichtungsstellglieder, um die Funktionsblocke dazu zu 
befahigen, die AusgangsgrbBen von brtlichen Sensoren zu 
lesen und die brtlichen Vorrichtungen mit Befehlen zu ver- 
sehen, um eine oder mehrere Funktionen, wie beispiels- 
weise das Bewegen eines Ventilteiles auszufiihren. Wandler- 

15 blbcke enthalten in typischer Weise Informationen, die er- 
forderlich sind, um Signale zu interpretieren, die durch eine 
brtliche Vbrrichtung abgeleitet wurden, und um in richtiger 
Weise die brtlichen Hardwarevorrichtungen zu steuern, wo- 
bei diese Informationen beispielsweise Information enthal- 

20 ten, die den Typ einer brtlichen Vorrichtung identifizieren, 
• Eichungsinformationen, die einer brtlichen Vorrichtung zu- 
geordnet sind, betreffen usw. Ein einzelner Wandlerblock ist 
in typischer Weise jedem Eingabe- oder Ausgabefunktions- 
block zugeordnet. 

25 Die meisten Funktionsblocke sind dazu befahigt, Alarm 
oder Ereignisanzeigen zu generieren, basierend auf vorbe- 
stimmten Kriterien, und haben' die Fahigkeit unterschiedlich 
in verschiedenen Modi zu arbeiten. Allgemein gesagt, kon- 
nen Funktionsblocke in einem automatischen Modus arbei- 

30 ten, in welchem beispielsweise der Algorithmus eines Funk- 
tionsblockes automatisch arbeitet; in einem Operatormodus 
arbeiten, in welchem der Eingang oder der Ausgang eines 
Funktionsblockes von Hand gesteuert wird; einem AuBer- 
Servicemodus arbeiten, in welche der Block nicht arbeitet; 

35 in einem Kaskadenmodus arbeiten, in welchem die Opera- 
tion des Blockes von der AusgabegrbBe eines verschiedenen 
Blbckes beeinfluBt wird (durch diesen bestirnmt wird); und 
in einem oder mehreren Entfernungsmodi arbeiten, in wel- 
chen ein entfernt gelegener Computer den , Modus, des 

40 Blocks bestirnmt. Es existieren jedoch in dem Fieldbus-Pro- 
tokoll andere Betriebsmodi. 

Als wichtiges Merkmal besitzt jeder Block die Fahigkeit, 
mit anderen Blbcken in der gleichen oder unterschiedlichen 
Bereichs vorrichtungen uber den Fieldbus-Bus zu kommuni- 

45 zieren, und zwar unter Verwendung von Standardnachrich- 
tenformaten, die durch das Fieldbus-Protokpll festgelegt 
sind. Als ein Ergebnis konnen Kombinationen von Funk- 
tionsblbcken (in den gleichen oder unterschiedlichen Vor- 
richtungen) miteinander kommunizieren, urn eine oder meh- 

50 rere dezentralisierte Regelschleifen zu erzeugen. Es kann 
somit beispielsweise ein PID-Funktionsblock in einer Be- 
reichsvorricntung iiber den Fieldbus-Bus angeschlossen 
sein, um eine AusgangsgrbBe eines AI-Funktionsblocks in 
einer zweiten Bereichsvorrichtung zu empfangen, um Daten 

55 an einen AO-Funktionsblock in einer dritten Bereichsvor- 
richtung zu liefern, um eine, AusgangsgrbBe eines AO- 
Funktionsblocks als RiickkopplungsgrbBe zu empfangen, 
um eine ProzeBregelschleife getrennt und neben irgendei- 
nem zentralisierten Kontroller zu erzeugen. Auf diese Weise 

60 bewegen 'Kombinationen vori Funktionsblbcken die Steuer- 
funktionen aus einer zentralisierten DCS-Umgebung heraus, 
was die Mbglichkeit schafft, daB DCS-Vieifunktionskon- 
troller tjberwachungs- oder Koordinations funktionen 
durchfuhren. Ferner erlauben es die Funktionsblocke, eine 

65 graphische blockorieritierte Struktur zu verwenden, und 
zwar eine einfache Konfiguration eines Prozesses, und er- 
mbglicheri die Verteilung der Funktionen unter den Be- 
reichsvorrichtungen von unterschiedlichen &ulieferern, da 
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diese Blocke ein konsistentes Kommunikationsprotokoll 
verwenden. 

Zusatzlich zu dem Merkmal, daB Bereichsvorrichtungen 
Blockobjekte enthalten und irnplementieren, enthalt jede 
Bereichsvorrichtung ein oder mehrere andere Objekte, in- 
klusive Verbindungsobjekten, Trendobjekten, Warnobjekten 
und Betrachtungsobjekten. Verbindungsobjekte definieren 
die Verbindungen zwischen den Eingangen und Ausgangen 
der Blocke (wie den Funktionsblocken), und zwar sowohl 
intern in der Bereichsvorrichtung als auch iiber den Field- 
bus-Bus hinweg. Trendobjekte erlauben einen ortlichen 
- Trend von Funktionsblockparametern fur den Zugriff auf 
andere Vorrichtungen, wie beispielsweise einen Host oder 
einen Kontroller. Trendobjekte halten historische Kurzzeit- 
daten, die einige, beispielsweise den Funktionsblockpara- 
meter, betreffen und berichten 'diese Daten an andere Vor- 
richtungen oder Funktionsblocke, und zwar iiber den Field- 
bus-Bus in einer asynchronen Weise. Wamobjekte berichten 
uber Alarme und Ereignisse liber den Fieldbus-Bus. Diese 
Alarme oder Ereignisse konnen irgendein Ereignis betref- 
fen, welches innerhalb einer Vorrichtung stattfindet oder in- 
nerhalb einem der Blocke einer Vorrichtung. Betrachtungs- 
objekte sind vordefinierte Gruppierungen von Blockpara- 
metern, die in standardisierten Mensch/Maschine-Schnitt- 
stellenbereichen verwendet werden und die zu anderen Vor- 
richtungen gesendet werden konnen, und zwar unter Ver- 
wendung von asynchronen Ubertragungen, um eine Be- 
trachtung von Zeit zu Zeit zu ermoglichen. 

In Fig. 2 sind drei Fieldbus-Vorrichtungen veranschau- 
licht, die beispielsweise aus irgendeiner der Bereichsvor- 
richtungen 43-50 von Fig. 1 bestehen, und diese enthalten 
Ressourcenblocke 58, Funktionsblocke 60, 61 oder 62 und 
Wandlerblocke 63 und 64. In der ersten Vorrichtung ist der 
Funktionsblock 60 (der aus einem Eingabefunktionsblock 
besteht) uber den Wandlerblock 63 mit einem Sensor 65 ge- 
koppelt, der beispielsweise aus einem Temperatursensor, ei- 
nem Sollpunktanzeigesensor usw. bestehen kann. In der 
zweiten Vorrichtung ist der Funktionsblock 61 (der aus ei- 
nem Ausgabefunktionsblock bestehen kann) uber den 
Wandlerblock 64 an eine Ausgabevorrichtung, wie bei- 
spielsweise ein Vehtil 66, gekoppelt. In der dritten Vorrich- 
tung enthalt der Funktionsblock 62 (der aus einem Steuer- 
funktionsblock bestehen kann) ein Trendobjekt 67, welches 
diesem zugeordnet ist, um den Trend, des Eingangsparame- 
ters des Funktionsblocks 62 zu ermitteln. 

Die Verbindungsobjekte 68 definieren die Verbindungen 
von Blockparametern yon jedem der zugeordneten Blocke 
und die Wamobjekte 69 erzeugen Alarme oder Ereignisbe- 
nachrichtigungen fur jeden der zugeordneten Blocke. Be- 
trachtungsobjekte 70 sind mit jedem der Funktionsblocke 
60, 61 und 62 zugeordnet und enthalten Gruppendatenlisten 
fur die Funktionsblocke, zu denen sie zugeordnet sind. 
Diese Listen enthalten Informationen, die fur jeden eines 
Satzes von unterschiedlich definierten Betrachtungen erfor- 
derlich sind. Naturlich stellen die Vorrichtungen von Fig. 2 
lediglich Beispiele dar und andere Zahlen und Typen von 
Blockobjekten, Verbindungsobjekten, Warnobjekten, 
Trendobjekten und Betrachtungsobjekten konnen in irgend- 
einer Bereichsvorrichtung vorgesehen sein. 

Um eine Kommunikation und Steueraktivitaten zu irnple- 
mentieren und auszufuhren, verwendet das Fieldbus-Proto- 
koll drei allgemeine Kategorien der Technologie, die als 
eine physikalische Schicht, als ein Kommunikations- n Sta- 
pel" und eine Anwenderschicht definiert sind. Die Anwen- 
derschicht enthalt die Steuer- und Konfigurationsfunktio- 
nen, die in Form der Blocke vorgesehen werden (wie bei- 
spielsweise den Funktionsblocken) und Objekte innerhalb 
irgendeiner bestimmten ProzeBsteuervorrichtung oder Be- 
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reichs vorrichtung. Die Anwenderschicht ist in typischer 
Weise in einer geschiitzten Weise ausgelegt oder konstruiert, 
und zwar durch den Hers teller der Vorrichtung, muB jedoch 
die Fahigkeit haben, Nachrichten zu empfangen und auszu- 
senden, und zwar in Einklang mit dem Standardnachrichten- 
format, welches durch das Fieldbus-Protokoll festgelegt ist, 
und muB durch einen Anwender in der standardisierten 
Weise konfigurierbar sein. Die physikalische Schicht und 
der Kommunikationsstapel sind erforderlich, um eine Nach- 
richtenverbindung zwischen unterschiediichen Blocken un- 
terschiedlicher Feld- oder Bereichsvorrichtungen in einer 
standardisierten Weise zu bewirken, und zwar unter Ver- 
wendung eines Zweidrahtbusses, und konnen durch das gut 
bekannte Open-Systems-Interconnect-(OSI)-Schicht-Kom- 
munikationsmodell modelliert sein. 

Die physikalische Schicht, die der OSI-Schicht 1 ent- 
spricht, ist in jeder Bereichsvorrichtung und in dem Bus ein- 
gebettet und arbeitet dahingehend, um elektromagnetische 
Signale, die von dem Fieldbus-Ubertragungsmedium. (dem 
Fieldbus-Zweidrahtbus) empfangen werden, in Nachrichten 
umzusetzen, die durch den Kommunikationsstapel der Be- 
reichsvorrichtung verwendet werden konnen. Die physikali- 
sche Schicht kann als ein Fieldbus-Bus und elektrornagneti- 
schen Signalen, die auf dem Bus an den Eingangen und Aus- 
gangen der Bereichsvorrichtungen vorhanden sind, betrach- 
tet werden. 

Der Kommunikationsstapel, der in jeder Fieldbus- Vor- 
richtung vorhanden ist, enthalt eine Datenverbindungs- 
schicht, die der OSI-Schicht 2 entspricht, eine Fieldbus-Zu- 
griffs-Sub-Schicht und eine Fieldbus-Nachricht-Spezifikati- 
onsschicht Die Anwenderschicht des Fieldbus-Protokolls 
besteht aus einer Schicht, die in dem OSI-Protbkoll nicht de- 
finiert ist. Jede Schicht in dem Kommunikationsstapel ist fur 
die Kodierung und Dekodierung eines Abschnitts der Nach- 
richt oder des Signals verantwortlich, welches iiber den 
Fieldbus-Bus ubertragen wird. Als ein Ergebnis addiert oder 
entfernt jede Schicht des Kommunikationsstapels gewisse 
Abschnitte des Fieldbus-Signals, wie beispielsweise die 
Praambeln, Startbegrenzer und Endebegrenzer, und in eini- 
gen Fallen, dekodiert sie Bandabschnitte des Fieldbus-Si- 
gnals, um eine Idehtifizierung dariiber durchzufiihren, ob 
der Rest des Signals oder der Nachricht gesendet werden 
sollte oder ob das Signal geloscht werden sollte, da es bei- 
spielsweise eine Nachricht oder Daten fur Funktionsblocke 
enthalt, die nicht innerhalb der empfangenden Bereichsvor- 
richtung vorhanden sind. 

Die Daten verbindungsschicht steuert die Ubertragung 
von Nachrichten auf dem Fieldbus-Bus und managt den Zu- 
griff auf den Bus gemaB einer deterministischen^zentrali- 
sierten Busablaufsteuerung (scheduler), der als ein verbin- 
dungsaktiver Abwickler bezeichnet wird, der im folgenden 
noch mehr in Einzelheiten beschrieben wird. Die Datenver- 
bindungsschicht entfernt eine Praambel von den Signalen 
auf dem Ubertragungsmedium und kann die empfangene 
Praambel verwenden, um den internen Takt der Bereichs- 
vorrichtung mit dem ankommenden Fieldbus-Signal zu syn- 
chronisieren. In ahnlicher Weise wandelt die Datenverbin- 
dungsschicht die Nachrichten auf dem Kommunikationssta- 
pel in physikalische Fieldbus- Signale um und kodiert diese 
Signale mit der Taktinformatipn, um ein "synchrones seriel- 
les" Signal mit einer richtigen Praambel fur die Ubertragung 
auf dem Zweidrahtbus oder -schleife zu erzeugen. Wahrend 
des Dekodierungsprozesses erkennt. die Datenverbindun'gs- 
schicht spezifische Kodes innerhalb der Praambel, wie bei- 
spielsweise Startbegrenzer und Endebegrenzer, um den An- 
fang und das Ende einer bestimmten Fieldbus-Nachricht zu 
idehtifizieren, und kann eine Prufsurnme erstellen, um die 
Integritat des Signals oder der Nachricht, die von dem Bus 
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empfangen wurde, zii verifizieren. In ahnlicher Weise iiber- 
tragt die Datenverbindungsschicht die Fieldbus-Signale auf . » 
den Bus, indem sie Start- und Endebegrenzer zu den Nach- 
richten auf dem Datenkommunikationsstapel hinzufiigt und 
indem sie diese Sighale auf das Ubertragungsmedium zu ei- 5 
ner geeigneten Zeit setzt. 

. Die Fieidbus-Nachrichten-Spezifikationsschicht erlaubt 
es der Anwenderschicht (das heiBt den Funktionsblocken, 
Objekten usw. einer Bereichsvorrichtung), iiber den Bus zu 
kommunizieren, und zwar unter Verwendung eines Stan- 10 
dardsatzes von Nachrichtenformaten und beschreibt den 
Kornmiinikationsservice, die Nachrichtenfprmate und die 
Protokollverhaltensweisen, die erforderlich sind, um Nach- 
richten herzustellen, die auf den Kommunikationsstapel zu 
setzeh sirid und die fur die Anwenderschicht vorzusehen 15 
sind. Da die Fieldbus-Nachrichteh-Spezifikationsschicht 
standardisierte Kommunikationen fur die Anwenderschicht 
liefert, sind spezifische Fieldbus-Nachrichten-Spezifikati- 
ons-Kornmunikationsdienste fur jeden Typ des bben be- 
schriebenen Objekts festgelegt; Bei spiels weise enthalt die 20 
Fieldbus-Nachrichten-Spezifikationsschicht Objektwortef- 
buchdienste, die es dem Anwender ermoglichen, in einem 
Objektworterbuch einer Vorrichtuhg zu lesen. Das Objekt- 
worterbuch speichert Objektbeschreibungen, welche jedes 
der Objekte beschreiben oder identifizieren (wie beispiels- 25 
, weise Blockobjekte), und zwar von einer Vorrichtung. Die 
Fieldbus-Nachrichten-Spezifikationsschicht ermoglicht 
auch variable Zugriffsdienste, die es einem Anwender er- 
moglichen, Kommunikationsbeziehungen, die als virtuelle 
Kommunikationsbeziehungen (VCRs) bekannt sind und im 30 
folgenden beschrieben werden, die einer oder mehreren Ob- 
jekten einer Vorrichtung zugeordnet sind, zu lesen und zu 
andern. Dartiber hinaus schafft die Fieldbus-Nachrichten- 
Sp.ezifikationsschicht ein Kontextmanagement, variable Zu- 
griffsdienste, Ereignisdienste, Hochlade- und Herunterlade- 35 
dienste und Programmaufrufdienste, die alle in Verbindung 
mit dem Fieldbus-Protokoll gut bekannt sind und daher hier 
nicht in Einzelheiten beschrieben werden. Die Fieldbus-Zu- 
gfiffs-Sub-Schicht bildet die Fieldbus-Nachrichten-Spezifi- 
kationsschicht in der Datenverbindungsschicht ab. 40 

Um einen Betrieb dieser Schichten zuzulassen oder zu er- 
moglichen, enthalt jede Fieldbus- Vorrichtung eine Manage- 
mentinformationsbasis (MIB), die aus einer Datenbasis oder 
Datenbank besteht, die VCRs, dynamische Variable, statisti- 
sche GrbBen, Zeitsteuerplane, Funktionsblockausfiihrungs- 45 
zeitsteuerplane und eine Vorrichtungsetikette (device tag) 
und Adresseninformationen speichert. Natiirlich konnen die 
Informationen innerhalb der MTB zugegriffen werden oder . 
zu irgendeiner Zeit "unter Verwendung der Standard-Field- 
bus-Nachrichten oder -Befehle geandert werden. Ferner ist 50 
gewohnlich eine Vorrichtungsbeschreibung fiir jede Vor- 
richtung vorgesehen, um einem Anwender oder einem Host 
einen weiten Uberblick an Informationen in der VFD zu ge- 
ben. Eine Vorrichtungsbeschreibung, die in typischer Weise 
in Form einer Sendeerlaubnis, um von einem Host verwen- 55 
det zu werden, festgelegt ist, speichert Informationen, die 
fiir den Host erforderlich sind, um die Bedeutung der Daten 
in den VFDs einer Vorrichtung zii verstehen. 

Wie ersehen werden kann, muB die Implementierung von 
irgendeiner Steuerstrategie unter Verwendung der Funk- 60 
tionsblocke, die tiber ein ProzeBregelnetzwerk verteilt ange- 
•ordnet sind, die Ausfiihrung der Funktionsblocke prazise 
geplant werden, und zwar in bezug auf die Ausfiihrung von 
anderen Funktionsblocken in einer bestimmten Regel- 
schleife. In ahnlicher Weise muB die Kommunikation zwi- 65 
schen'unterschiedlichen FunktionsbLockeh in praziser Weise 
auf dem Bus geplant werden, so daB die richtigen Daten zu 
jedem Funktionsblock ubertragen werden, bevor dieser 



Block ein Programm ausfuhrt. 

Der Weg, mit welchem unterschiedliche Bereichsvorrich- 
tungen (und unterschiedliche Blocke innerhalb den Be- 
reichsvorrichtungen) iiber das Fieldbus-Ubertragungsme- 
dium kommunizieren, soli nun beschrieben werden. Damit 
eine Kommunikation stattfindet, arbeitet eine der Verbin- 
dungsmastervorrichtungen auf jedem Segment der Field- 
bus-Schleife als ein verbindungsaktiver Abwickler (LAS), 
der aktiv die Kommunikation auf dem zugeordneten Seg- 
ment des Busses abwickelt und steuert. Das LAS fur jedes 
Segment des Busses speichert einen Kommunikation splan 
(einen verbindungsaktiven Plan), der Zeitpunkte enthalt, bei 
denen jeder Funktionsblock von jeder Vorrichtung geplant 
ist, periodisch die Kommunikationsaktivitat auf dem Bus zu 
starten und auch die Lange der Zeit geplant ist, wahrend 
welcher diese Kommunikationsaktivitat stattfinden muB. 
Wahrend lediglich eine und nur eine aktive LAS -Vorrich- 
tung auf jedem Segment des Busses vorhanden sein kann, 
konnen andere Verbindungsmastervorrichtungen als Bak- 
kup-LASs dienen und konnen beispiels weise dann aktiv 
werden,. wenn die momentane LAS ausfallt. Die Basisvor- 
richtungen haben nicht die Fahigkeit, eine LAS zu irgendei- 
nem Zeitpunkt zu werden. 

Allgemein gesagt, werden die Kommunikationsaktivita- 
ten iiber den Bus eingeteilt in Wiederholungsmakrozyklen, 
die den synchronen Kommunikationsplan fiir den Bus defl- 
nieren. Eine Vorrichtung kann aktiv sein, das heiBt Daten zu 
irgendeinem Segment des Busses senden oder von diesem 
empfangen, und zwar selbst wenn sie physikalisch an ein 
unterschiedliches Segment des Busses angeschlossen ist, 
und zwar durch eine koordinierte Operation der Briicken 
und der LASs auf dem Bus. j 

Wahrend jedes Makrozyklusses fiihrt jeder -der Funk- 
tionsblocke, die auf einem bestimmten Segment des Busses 
aktiv sind, gewohnlich zu einem unterschiedlichen, jedoch 
prazise geplanten (synchronen) Zeitpunkt oder Zeit ein Pro- ' 
gramm durch. Wenn der Funktionsblock einen Ausgangspa- 
rameter hat, der mit einem anderen Parameter extern zu der 
Vorrichtung verkettet ist, so veroffentlicht der Funktions- 
block seine Ausgangsdaten in einer. prazise geplanten Zeit 
im Ansprechen auf einen Erzwingungsdatenbefehl, der 
durch die LAS erzeugt wurde. In bevorzugter Weise ist jeder - 
Funktionsblock so eingeplant, daB er seine Ausgabedaten » 
kurz nach dem Ende der Ausfuhrungsperiode des Funk-, 
tionsblockes veroffentlicht. Ferner sind die Datenveroffent- 
lichungszeitpunkte der verschiedenen Funktionsblocke in v 
serieller Form geplant oder einer Ablaufsteuerung unterwor- ■• 
fen, so daB.keine zwei Funktionsblocke auf einem bestimm- . 
ten Segment des Busses Daten zur gleichen Zeit veroffentli- 
chen. Wahrend der Zeit, wahrend welcher eine synchrone 
Kommunikation nicht stattfindet, hat jede Bereichsvorrich- 
tung die Moglichkeit, ihrerseits Alarrhdaten, Betrachtungs- 
daten usw. in einer asyrichronen Weise zu senden, und zwar 
unter Verwendung von sendeanfrage-angetriebenen Kom- 
munikationen. Der Ausfuhrungs- oder Ablaufplan ist in ei- 
ner Mangementinformationsbasis (MIB) abgespeichert, es 
sind die Ausfuhrungszeitpunkte der Blocke in den Funk- 
tionsblocken gespeichert und es sind die Zeitpunkte zum 
Senden der Zwangsdatenbefehle zu jeder der Vorrichtungen 
auf einem Segment des Busses in der MIB der LAS- Vorrich- 
tung fur. dieses Segment gespeichert. Diese Zeitpunkte wer- 
den in typischer Weise als Offsetzeiten gespeichert, da sie 
die Zeiten oder Zeitpunkte identifizieren, zu welchen Funk- 
tionsblock • ein Programm ausfiihren oder Daten senden 
muB, und zwar in einer Versetzung (Offset)' vom Anfang ei- 
ner "absoluten Verbindungsplanstartzeit", die alien Vorrich- 
tungen, die an den Bus angeschlossen sind, bekannt ist. 

Um Kommunikationen zwischen jedem Makrozyklus zu 
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bewirken, sendet die LAS einen Zwangsdatenbefehl zu je- 
der der Vorrichtungen auf dem zugeordneten Bussegment 
gemaB der Liste der Sendezeitpunkte, die in dem verbhv 
dungsaktiven Plan gespeichert sind. Nach dem Empfang ei- 
nes Zwangsdatenbefehls verofTentlicht ein Funktionsblock 
einer Vorrichtung seine Ausgabedaten auf dem Bus. Da je- 
der der Funktionsblocke typischerweise einer Ablaufsteue- 
rung unterliegt, um ein Programm aus zufuhren, so daB die 
Ausfiihrung des Programms dieses Blocks vervollstandigt 
wird, kurz bevor der Block im Plan dafur vorgesehen ist, ei- 
nen Zwangsdatenbefehl zu empfangen, sollten die Daten, 
die im Ansprechen auf einen Zwangsdatenbefehl veroffent- 
licht werden, die allerletzten Ausgangsdaten des Funktions- 
blockes sein. Wenn jedoch ein Funktionsblock in der Pro- 
grammausfuhrung langsam ist und keine neuen Ausgangs- 
groBen verriegelt hat, wenn er den Zwangsdatenbefehl emp- 
fangt, veroffentlicht der Funktionsblock die Ausgangsdaten, 
die wahrend des letzten Laufes des Funktionsblockes er- 
zeugt wurden. 

Wahrend der Perioden, in welchen die Zwangsdatenver- 
offentlichungen nicht geplant sind, kann die LAS asyn- 
chrone Kommunikationsaktivitaten aktivieren. Um eine 
asynchrone Kommunikation zu bewirken, sendet die LAS 
eine DurchlaB-Token-Nachricht zu einer bestimmten Be- 
reichsvorrichtung. Wenn eine Bereichsvorrichtung eine 
DurchlaB-Token-Nachricht empfangt, erlangt diese Be- 
reichsvorrichtung vollen Zugriff auf den Bus (oder ein Seg- 
ment desselben) und kann asynchron Nachrichten senden, 
wie .beispielsweise Alarmnachrichten, Trenddaten, Opera- 
tor-Soilpunktanderungen usw., bis die Nachrichten vervoll- 
standigt sind oder bis eine maximal zugewiesene "Token- 
Haltezeit" verstrichen ist. Danach gibt die Feld vorrichtung 
den Bus frei (oder .'irgendein bestimmtes Segment dessel- 
1 ben) und die LAS sendet eine DurchlaB-Token-NaChricht zu 
einer anderen Vorrichtung. Dieser ProzeB wird wiederholt, 
bis die LAS entweder gemaB dem Plan einen Zwangsdaten- 
befehl aussendet, um eine synchrone Kommunikation zu be- 
wirken, oder die LAS eine Netzwerkwartung durchzufuhren 
hat. Naturlich kann abhangig vom AusmaB des Nachrich- 
teriverkehrs und der Zahl der Vorrichtung und der Blocke, 
die an ein bestimmtes Segment des Busses gekoppelt sind, 
nicht jede Vorrichtung eine DurchlaB-Token-Nachricht wah- 
rend jedes Makrozyklusses empfangen. 

Fig. 3 veranschaulicht ein Zeitsteuerschema, welches die 
Zeitp.unkte herausgreift, bei den die Funktionsblocke (mit 
AL L00 Pb PIDloopi, AI LO op2, AO LO opi> SS LO op2 und PID- 
L00 P3) ein Programm ausfiihren, und zwar wahrend jedes 
Makrozyklusses eines Bussegmentes, und die Zeitpunkte, 
bei denen eine synchrone Kommunikation wahrend. jedes 
Makrozyklusses stattfindet, der dem Bussegment zugeord- 
. net ist; In dem Zeitsteuerplan von Fig. 3 ist die Zeit auf der 
. horizontalen Achse aufgetragen und die Aktivitaten, die den 
unterschiedUchen Funktionsblocken zugeordnet sind, sind 
auf der vertikalen Achse veranschaulicht. Die Regelschleife 
(die zum Zwecke der Erlauterung willkurlich ist), in welcher 
jeder der Funktionsblocke arbeitet, ist in Fig. 3 als Indexan- 
gabe identifiziert. Somit verweist AI LO opi auf den AI-Funk- 
tionsblock von beispielsweise einem Sender, der innerhalb 
, einer ersten Regelschleife arbeitet, PID L oopi verweist auf 
den PID-Funktionsblock in beispielsweise einem Stellwerk/ 
Ventil, welches innerhalb der ersten Regelschleife arbeitet, 
usw. Die Blockausfuhrungsperiode von jedem der veran- 
schaulichten Funktionsblocke ist durch ein kreuzstrichUer- 
tes Kastchen herausgestellt, wahrend jede geplante syn- 
chrone Kommunikation durch einen vertikalen Balken in 
Fig. 3 identifiziert ist. 

Somit fuhrt gemaB dem Zeitsteuerplan von Fig. 3 wah- 
rend irgendeines bestimmten Makrozyklusses des Busseg- 



ments der AI L oopr Funktionsblock: zuerst ein Pr °g ramm 
aus, und zwar fur die Zeitperiode, die durch das Kastchen 71 
spezifiziert ist. Dann, wahrend der Zeitperiode, die durch 
den vertikalen Balken 72 angezeigt ist, wird die Ausgangs- 
5 groBe des AI L oopr Funkuonsblockes auf dem Bussegment 
im Ansprechen auf einen Zwangsdatenbefehl von der LAS 
fur das Bussegment veroffentlicht. In ahnlicher Weise zei- 
gen die Kastchen 74, 76, 78, 80 und 80 die Ausfuhrungszei- 
ten der jeweiligen Funktionsblocke PID LO opi» AI LO op2, AO- 
10 Loopb SS LO0 P2 und PID L oop3, die fur jeden der unterschied- 
Uchen Blocke verschieden sind, an, wahrend die vertikalen 
■ Balken 82, 84, 86, 88 und 89 die Zeiten anzeigen, zu wel- 
chen die jeweiligen Funktionsblocke PID L oopi> AI LO op2> 
AOloopi.. SS LO op2 und Pm L00 P3 Daten auf dem Busseg- 
15 ment veroff entlichen. 

Wie zu erkennen ist, veranschaulicht das Zeitsteuer- 
schema von Fig. 3 auch die Zeitpunkte oder Zeiten, die fur 
asynchrone Kommunikationsaktivitaten verfugbar sind, die 
wahrend der Ausfuhrungszeiten von irgendeinem der Funk- 
20 tionsblocke auftreten konnen und wahrend der Zeit am Ende 
des Makrozyklusses, wahrend welcher keiner der Funk- 
tionsblocke ein Programm ausfuhrt und wenn keine syn- 
chrone Kommunikation auf dem Bussegment stattfindet. ' 
Wenn es naturlich gewiinscht wird, konnen unterschiedliche 
25 Funktionsblocke beabsichtigt so eingeplant werden, daB sie 
ein Programm zur gleichen Zeit ausfiihren und daB nicht alle 
Funktionsblocke Daten auf dem Bus veroffentlichen mus- 
sen, wenn beispielsweise keine andere Vorrichtung an den 
Datenteil hat, die durch einen Funktionsblock erzeugt wer- 

30 den. t 

Bereichsvorrichtungen konnen Daten veroffenthchen 
oder ubertragen und konnen Nachrichten iiber den Fieldbus- 
Bus ubertragen, und zwar unter Verwendung von einer der 
drei virtuellen Kommunikationsbeziehungen (VCRs), die in. 
35 der Fieldbus-Zugriffs-Sub-Schicht des Stapels von jeder Be- 
reichsvorrichtung definiert sind. Ein CUentyServer-VCR. 
wird fur in eine Warteschlange eingereihte, nicht geplante, 
vom Anwender initialisierte Eins-zu-Eins-Kommunikatio- 
nen zwischen den Vorrichtungen auf dem Bus verwendet. 
40 Solche in eine Warteschlange eingereihten Nachrichten wer- 
den in der Reihenfolge gesendet und empfangen, wie sie fur 
die Aussendung geliefert werden, und zwar gemaB deren 
Prioritat, ohne daB dabei fruhere Nachrichten uberschrieben 
werden, Somit kann eine Bereichsvorrichtung einen Client/ 
45 Server- VCR verwenden, wenn sie eine DurchlaB-Token- 
Nachricht von einem LAS empfangt, um eine Anfragenach- 
richt zu einer anderen Vorrichtung auf dem Fieldbus-Bus zu 
senden. Der Anfrager wird als "Client" bezeichnet und die 
. Vorrichtung, die die Anfrage empfangt, wird als "Server" 
50 bezeichnet. Der Server sendet eine Antwort, wenn er eine 
Durchgangs-Token-Nachricht von dem LAS empfangt. Der 
Client/Server- VCR wird beispielsweise dazu verwendet, um 
operator-initialisierte Anfragen, wie beispielsweise Soli- 
punktanderungen, Abstimmparameter, Zugriff und Ande- 
55 rungen, Alarmbestatigungen und Vorrichtungs-up und - 
downloads zu bewirken. 

Ein Reportverteiler VCR wird fur die in eine Warte- 
schlange eingereiht, nicht geplanten, anwenderinitialisierten 
Kommunikationen von einer bis mehreren Kommunikatio- 
60 nen verwendet. Wenn beispielsweise eine Bereichsvorrich- 
tun g mit einem Ereignis- oder einem Trendreport ein Durch- 
gangs-Token von einer LAS empfangt, so sendet diese Be- 
reichsvorrichtung ihre Nachricht zu einer "Gruppen- 
adresse", die in der Fieldbus-Zugriffs-Sub-Schicht des 
65 Kommunikationsstapels dieser Vorrichtung definiert ist. Die 
Vorrichtungen, die dafur konflguriert sind, um auf dieses 
VCR zu horchen, werden den Report empfangen. Der Re- 
portverteilungs-VCR-Typ wird in typischer Weise durch die 
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Fieldbus-Vorrichtungen verwendet, um Alarmbenachrichti- 
gungen zu Bedienungskonsolen zu senden. 

Ein Herausgeber/Benutzer-VCR-Typ wird dazu verwen- 
det, um eine bis viele Kommunikationen zu puffern. Die ge- 
pufferten Kommunikationen sind solche, die lediglich die 
spateste Version der Daten speichem und senden und es 
uberschreiben daher neue Daten vollstandig die friiheren 
Daten. Die FunktionsausgangsgroBen umfassen beispiels- 
weise gepufferte Daten. Eine "Ver6ffentbcher"-Bereichs- 
vorrichtung veroffentlicht oder sendet eine Nachricht unter 
Verwendung des Veroffentlicher/Benutzer-VCR-'typs an 
alle die "Benutzer"-Bereichs-vorrichtungen an den Field- 
bus-Bus, wenn die Veroffentlichervorrichtung eine Zwangs- 
datennachricht von der LAS oder von einer Benutzer- oder 
Teilnehmervorrichtung empfangt. Die Veroffentlicher-/Be- 
nutzerbeziehungen sind vorbestimmt und sind innerhalb der 
Fieldbus-Zugriffs-Sub-Schicht des Kommunikationsstapels 
von jeder Bereichs vorrichtung definiert und gespeichert. 

Um richtige Kommunikationsaktivitaten iiber den Field- 
bus-Bus sicherzustellen, sendet jede LAS periodisch eine 
Zeitverteilungsnachricht an alle Bereichsvorrichtungen, die 
an ein Segment des Busses angeschlossen sind, was des den 
empfangenden Vorrichtungen ermoglicht, ihre ortliche Da- 
tenverbindungszeit so einzustellen, daB sie miteinander syn- 
chronisiert sind. Zwischen diesen Synchronisationsnach- 
richten wird die.Taktzeit unabhangig in jeder Vorrichtung 
beibehalten, und zwar basierend auf deren eigenem inter- 
nem Takt. Eine Taktsynchronisation erlaubt es den Be- 
reichsvorrichtungen, die Funktionsblock-Programmausfuh- 
rung mit dem Netzwerk zu synchronisieren. 

Wie aus der oben gegebenen Erlauterung des Fieldbus- 
Kommunikationsprotokolls hervorgeht, erfordert eine Kom- 
munikation mit irgendeiner speziellen Vorrichtung oder ei- 
nem Funktionsblock, der innerhalb des Fieldbus-Abschnitts 
des ProzeBregelnetzwerks 10 gelegen ist, das heiBt an den 
Bus 42 angeschlossen ist, detailliertes Wissen daruber, auf 
welche Weise die Kommunikation innerhalb des Fieldbus- 
Protokolls im allgemeirien bewirkt wird, als auch eine Be- 
trachtung daruber und ein Wissen davon, wie der Fieldbus- 
Bus'42 speziell aufgebaut ist und wann Kommunikationen, 
die diesem zugeordnet sind, geplant sind und erlaubt wer- 
den. Dies macht es seinerseits fur den Designer der ProzeB- 
regelroutine schwierig, die in dem Kontroller 12 implemen- 
tiert ist, Kommunikationen mit den Vorrichtungen innerhalb 
des Fieldbus-Abschnitts des ProzeBregelnetzwerks zu im- 
plementieren und zu planen, das heiBt den \brrichtungen, 
die an den Bus 42 angeschlossen sind. Da daruber hinaus 
Standard- oder regulare Kommunikationen zwischen. den 
Funktionsblocken in einer synchronen Weise iiber den Bus 
42 erfolgen, rnuB der Kontroller 12 so konfiguriert sein, um 
all diese Kommunikationen oder Nachrichten oder wenig- 
stens die einen zu empfangen, die er zur Ausfiihrung der 
Steuer- oder Regelroutine benotigt. Es kann eine entmuti- 
gende Aufgabe auf Seiten des Kontrollers 12 werden, den 
Empfang und die Speicherung von all den Informationen zu 
koordinieren, die auf dem Bus 42 flieBen, und zwar in einer 
Weise, die effizient durch den Kontroller 12 verwendet wer- 
den kann, um die Steuerung des gesamten Prozesses 19 zu 
bewirken. Um ferner Informationen zu empfangen, die nicht 
synchron iiber den Bus 42 gesendet werden, muB der Kon- 
troller 12 eine Anfrage nach dieser Information aussenden, 
die, wie oben erlautert wurde, asynchron uber den Bus 42 
gesendet wird. Da es fur den Kontroller 12 keineri Weg gibt, 
zu bestimmen oder zu bewirken, wann die asynchrone An- 
frage an die geeignete Vorrichtung ubergeben wird (da die 
Zeitsteuerung diese Anfrage direkt durch die anderen asyn- 
chronen Kommunikationen beeinfluBt wird, die auf dem 
Bus 42 stattfinden), kann der Kontroller 12 Informationen 



empfangen, die nicht mehr aktuell sind, und zwar zu dem 
Zeitpunkt, wenn sie den Kontroller 12 erreichen. In ahnli- 
cher Weise hat der Kontroller 12 keine Moglichkeit zu be- 
stimmen, welche Daten es zu einem spezifischen Zeitpunkt 
5 sein sollen oder waren, was bei der Steuerung anderer Vor- 
richtungen innerhalb des Prozesses 19 wichtig sein kann, die 
nicht an den Bus 42 angeschlossen sind. Daruber hinaus 
kann es schwierig oder unmoglich fur den Kontroller 12 
sein, wichtige Informationen zu empfangen, die den Status 

10' einer Vorrichtung ' oder eines Funktionsblockes betreffen, 
und zwar innerhalb des Fieldbus-Abschnitts des Prozesses 
' 19, wie beispielsweise Alarme, die durch solche Funktions- 
blocke erzeugt werden. 

Um diese Probleme zu iiberwinden, kann der Kontroller 

15 12 so ausgelegt sein, um die Schattenfunktionsblocke zu 
verwenden, um die Kommunikation mit den Vorrichtungen 
und den Funktionsblocken innerhalb des Fieldbus-Ab- 
schnitts des ProzeBregelnetzwerks 10 zu implementieren. 
Spezieiler gesagt, kann die Steuerroutine innerhalb des 

20 Kontrollers 12 direkt mit einem Schattenfunktionsblock in- 
nerhalb des Kontrollers 12 kommunizieren, der dann auto- 
matisch mit einem zugeordneten aktuellen externen Funk- 
tionsblock innerhalb einer Bereichsvorrichtung kommuni- 
ziert, die an den Bus 42 angeschlossen ist. Der Schatten- 

25 funktionsblock innerhalb des Kontrollers 12 ist so konfigu- 
riert, um den Stand der und die Daten, die dem aktuellen ex- 
ternen Funktionsblock zugeordnet sind, innerhalb einer Vor- 
• richtung nach unten ,zu spiegeln, die an den Bus 42 ange- 
schlossen ist, so daB es fur die ProzeBsteuerroutinen inner- 

30 halb des Kontrollers 12 so scheint, als ob der tatsachliche 
externe Funktionsblock zugreifbar ist, ohne vermittels des 
Fieldbus-Protokolls uber den Bus 42 kommunizieren zu 
■miissen. Mit anderen Worten erscheint es fur die ProzeB- 
steuerroutine innerhalb des Kontrollers 12 so, als ob der tat- 

35 sachliche Funktionsblock innerhalb des ProzeBkontrollers 
12 gelegen ware, anstatt unten innerhalb einer externen Be- 
reichsvorrichtung, die an den Bus angeschlossen ist, und die 
ProzeB steuerroutine verwendet den Schattenfunktionsblock 
so wie sie andere Funktionsblocke innerhalb des Kontrollers 

40 12 verwendet. 

Fig. 4 veranschaulicht eine graphische Einzelheit einer 
ProzeBregelschleife oder eines Moduls 100, der der ProzeB- 
steuerroutine zugeordnet ist und durch diese implement! ert 
ist, und zwar innerhalb des ProzeBkontrollers 12. Um die 

45 Steuerung des gesamten Prozesses 19 zu implementieren, 
kann die ProzeBsteuer- oder -regelroutine innerhalb des 
Kontrollers 12 viele solcher Schleifen oder Module imple- 
mentieren, die in irgendeiner gewiinschten Weise miteinan- 
der verbunden sein konnen. Die herausgegriffene ProzeBre- 

50 gelschleife 100 enthalt eine Representation eines Aspektes 
(Flusses) des Prozesses 101, der durch eine Anzahl von 
Kontroilerblocken oder Einheiten gesteuert wird, speziell 
durch einen PID-Block 102, der an einen AO-Block 104, ei- 
nen ersten AI-Block 106 und einen zweiten AI-Block 108 

55 gekoppelt ist. Jeder der Blocke 102, 104 und 106 ist eine 
graphische Einzeldarstellung einer Regelsubroutine (oder 
eines Objektes innerhalb einer objektprientierten Program- 
mierumgeburig), die der ProzeBregelroutine zugeordnet ist, 
die in dem Kontroller 12 ge'speichert ist, konfiguriert gemaB 

60 einem Kontrollerprotokoll, welches dem Kontroller 12 zu- 
geordnet ist und dazu verwendet wird, um einen Abschnitt 
. einer Gesamtregelstrategie in bezug auf den ProzeB 101 zu 
implementieren. Jeder der Blocke der ProzeBregelroutine 
100 enthalt Eingange und Ausgange (durch Eingange auf 

65 der linken und rechten Seite der Blocke jeweils veranschau- 
licht) und kann einen Steuer- oder Regelalgorithmus enthal- 
ten, der eine gewisse Steuer- oderRegelfunktion durchfuhrt. 
Verbindungen untereinander oder Verbindungen zwischen 
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den Funktionsblocken sind als Leitungen oder Linien darge- 
stellt, die von einem Ausgang von einem Block zu einem 
Eingang eines anderen Blocks verlaufen. Diese Verbindun- 
gen geben die Art wieder, in welcher die Kommunikation 
zwischen den eirizelnen Blocken innerhalb der Steuerrou- 
tine oder Modul implementiert wird, um eine ProzeBregel- 
schleife gemaB einem Kontrollerprotokoll auszufuhren. So- 
mit veranschaulicht die Einzelheit von Fig. 4 nicht nur die 
Elemente der Regelschleife, die ausgefiihrt werden, sondern 
auch die Aft, in welcher die ProzeBregelroutine innerhalb 
des Kontrollers 12 ausgelegt ist, um diese Schleife zu imple- 
mentieren. Die ProzeBregelroutine kann automatisch gean- 
dert oder erneut konfiguriert werden, und zwar durch Bewe- 
gen der Verbindungen zwischen den Blocken, durch Addie- 
ren oder Weglassen von Blocken davon usw., wie dies durch 
den Delta V-ProzeBkontroller ausgefiihrt wird. 

Der PID-Funktionsblock 102, der in Fig. 4 veranschau- 
licht ist, enthalt einen Algorithmus (durch den Kontroller 12 
implementiert), der beispielsweise eine Proportionai/Inte- 



werden, urid zwar unter Verwendung eines Delta V-Steuer- 
systems(oder eines anderen zentralisierten Steuersy stems), 
bei dem der .Basissatz an Funktionsblocken, die in dem 
Steuersystem oder Regelsystem verwendet werden, ahnlich 
5 denjenigen ist, die durch das Fieldbus-Protokoll definiert 
sind. Die externen Fieldbus- oder herstellerspezifischen 
Funktionsblocke sind individuell zugeordnet, um in Verbin- 
dung mit dem Steuer- oder Regelsystem (oder einem TeiL 
des Steuer- oder Regelsystems) ein Programm auszufuhren 
10 und die Funktionsblocke der Fieldbus- Vorrichtungen sind in 
dem Steuer- oder Regelsystem als Schattenfunktionsblocke 
wiedergegeben oder reflektiert, welche interne und externe 
Referenzen unterstutzen, so als ob die externen Funktions- 
blocke in dem Steuer- oder Regelsystem vorhanden waren. 
15 Das Steuer- oder Regelsystem erneuert automatisch die dy- 
namischen und die statischeri Parameter des Schattenf unkti- 
onsblocks und leitet Anderungsanfragen zu den geeigneten 
externen Funktionsblocken unter Verwendung der Schatten- 
funktionsblocke. Alarmsignale, die in den externen Vorrich- 



gral/Differential-Regelberechnung ausfuhrt, basierend auf 20 tungen (oder Funktionsblocken) detektiert werden, werden 



den EingangsgroBen, die er von den AI-Blocken 106 und 
108 und dem AO-Block 104 empfangt, und der ein Aus- 
gangssteuersignal fur den AO-Block 104 erzeugt, welcher 
seinerseits eine Vorrichtung (28 beispielsweise ein Ventil) 
innerhalb des Prozesses 101 veranlaBt, eine Funktion durch- 
zufuhren, wie beispielsweise bewirken, daB ein Ventil be- 
wegt wird, um die Stromung eines Mediums zu erhohen. 
Der AO-Block 104 kann einem tatsachlichen Ventil zuge- 
ordnet sein und dieses steuern, z. B. das Ventil 28 von Fig. 1, 
und zwar iiber die IO- Vorrichtung 20 und die 4-20-mA- 
Kommunikationsleitung 38. Der AO-Block 104 empfangt 
• eine Messung der tatsachlichen Position des Ventils und lie- 
fert diese Messung als eine RiickkopplungsgroBe zu dem 
PID-Funktiorisbiock 102 uber die Verbindung 110. Daruber 
hinaus empfangt der PID-Funktionsblock 102 Eingangsgro- 
Ben von dem AI-Block 106, der beispielsweise einem Sen- 
sor, wie einem Temperatursensor, zugeordnet ist, der inner- 
halb des Prozesses 19 gelegen ist. Dieser Sensor kann bei- 
spielsweise der Sensor 34 von Fig. 1 sein, in welchem Fall 
der AI-Block 106 die SensormeBgroBen uber die I/O- Vor- 
richtung 22 empfangt, und zwar unter Verwendung von 
Standardnachrichtenubertragungen. Solch eine Verbindung 
ist in Fig. 4 durch die Verbindung zwischen dem Ausgang, 
der mit "FluB" in dem ProzeB 101 bezeichnet ist, und dem 
Eingang des AI-B locks 106, der mit "simulatejn" bezeich- 
net ist, veranschaulicht. Die Verarbeitung und die Steuerung 
der Information, die dem PID-Funktionsblock 102, dem 
AO-Block 104 und dem.AI-Block 106 zugeordnet ist, wird 
innerhalb des Kontrollers 12 durchgefuhrt. 



in den Schattenfunktionsblocken reflektiert und werden in 
der Alarmverarbeitung des Steuer- oder Regelsystems inte- 
griert. Natiirlich kommuniziert der Schattenf unktionsblock 
mit den . externen Funktionsblocken unter Verwendung des 
25 Kontrollerprotokolls, welches den externen Funktionsblok- 
ken zugeordnet ist, welches verschieden von dem Kontrol- 
lerkonfigurationsprotokoll sein kann und typischerweise 
verschieden ist, welches von dem Kontroller verwendet 
wird, um die Kommunikationen zwischen den Funktions- 
30 blocken intern zu dem Kontroller zu implementieren. Auch 
konnen Verbindungen zwischen internen und externen 
Funktionsblocken durch den Anwender in einer Weise be- 
stimmt werden, die davon abhangt, wo der Funktionsblock 
vorhanden ist. Als ein Ergebnis erscheinen wahrend der 
35 Steuerdefinition und der Online-Diagnose die Funktions- 
blocke als die gleichen, ob sie nun interne (in dem Steuer- 
oder Regelsystem vorhanden) oder externe (in einer Field- 
bus- Vorrichtung vorhanden) sind oder nicht. , 
Somit ist gemaB der vorliegenden Erfindung der AI- 
40 Block 108, der in Fig. 4 so dargestellt ist, daB er ahnlich dem 
AI-Block 106 ist, tatsachlich ein Schattenfunktionsblock, 
der so konfiguriert ist, daB er mit einem externen Funktions- 
block 112 kommuniziert, der beispielsweise innerhalb des 
Sensors 48 gelegen ist, der an den Fieldbus 42 von Fig. 1 an- 
geschlossen ist. Der Schattenfunktionsblock 108 liefert ge- 
messene oder andere Signale, die dem externen Funktion s-. 
block 112 zugeordnet sind, an den PID-Block 102 iiber die 
Verbindungen, die dazwischen erstellt wurden. Um anzuzei- 
gen, daB der Block 108 ein Schattenfunktionsblock ist, der 



45 



Allgemein gesagt, ist innerhalb .des Delta V-Steuersy- 50 einem externen Funktionsblock 112 zugeordnet ist und mit 



stems, das heiBt Verwendung des Delta V-Kontrollerkonfi- 
gurationsprotokolls jeder der Blocke 102, 104 und 106 spe- 
zifisch konfiguriert, um all die Informationen und Daten zu 
unterstutzen, die den ahnlichen Funktionsblocken in dem 
Fieldbus-Protokoll zugeordnet sind und somit fur alle Ab- 
sichten und Zwecke, und ist sehr ahnlich einem Funktions- 
block innerhalb des Fieldbus-Protokolls mit der Ausnahme, 
daB die Steuerfunktionen oder Regelfunktionen durch den 
zentralen Prozessor 12 durchgefuhrt werden und daB die In- 
formationen von speziellen Bereichs vorrichtungen iiber 
Standardkommunikationsleitungen von dem ProzeBkontrol- 
ler 12 empfangen und ubergeben werden. Somit sind die 
Abschnitte der Steuer- oder Regelroutine, die in Fig. 4 her- 
ausgegriffen ist, welche die Blocke 102, 104 und 106 ent- 
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diesem kommuniziert, unter Verwendung des,Kommunika- 
tionsprotokolls des externen Funktionsblockes 112, ist der 
Block 108 so dargestellt, daB er eine strichlierte Linie be- 
sitzt, die an den AI-Funktionsblock 112 innerhalb der Field- 
bus- Vorrichtung 48 angehangt ist. Jedoch' kann der Schat- 
tenfunktionsblock 108 so dargestellt sein, daB er eine Vor- 
richtungsetikette (device tag) und/oder einen Blocknamen 
am Boden desselben besitzt, oder kann in irgendeiner ande- 
ren gewiinschten Weise dargestellt sein, wobei darauf hinge- 
wieseri sei, daB die Art, in welcher der Schattenfunktions- 
block fur einen Anwender als Einzelheit dargestellt ist, nicht 
kritisch ist, und zwar in Verbindung mit dem Betrieb des 
Schattenfunktionsblocks. Ferner werden die Eingangsgro- 
Ben und AusgangsgroBen, die dem AI-Funktionsblock 112 



halt, momentan in der Delta V-Umgebung vqrgesehen und 65 zugeordnet sind, innerhalb des Fieldbus-Netzwerks gemaB 
sind bekannt. . dem Weg ubergeben, in welchem das Netzwerk konfiguriert 

Um die Fieldbus-Integration innerhalb des Kontrollers 12 worden ist. 



zu unterstutzen, kann die folgende Annaherung versucht 



Wahrend der Schattenfunktionsblock 108 auf alle oder 
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die meisten der Informationen zugreift oder spiegelt, die 
dem tatsachlichen Funktionsblock 112 zugeordnet sind und/ 
oder durch diesen erzeugt werden, erfolgt irgendeine Verar- 
beitung, die in bezug auf die AI-Funktionsblock 112 stattfln- 
det (oder in bezug auf irgendeinen anderen Funktionsblock, 
fur den ein Schattenfunktionsblock existiert) in dieser Weise 
unten in der externen Vorrichtung, nicht in dem Schatten- 
funktionsblock 108 oder.selbst in dem Kontroller 12. Als ein 
Ergebnis kann der Schattenfunktionsblock 108 so betrachtet 
werden, als ob er eine Rohre von Informationen zwischen 
dem PID-Block 102 (oder irgendeinem anderen Block in- 
nerhalb des zentralisiertdn Kontrollers 12) urid dem tatsach- 
lichen Funktionsblock 112 bilden wiirde. Der Schattenfunk- 
tionsblock 108 ist nicht ein Funktionsblock, der vollstandig 
durch den Kontroller 12 betreibbar ist, in dem Sinn, daB der 
AI-Block 106 und der PID-Block 102 durch den Kontroller 
12 betreibbar sind, da der Schattenfunktionsblock 108 ledig- 
lich die Informationen innerhalb des tatsachlichen externen 
Funktionsblocks 112 spiegelt oder ansonsten eine Nachrich- 
tenubeftragung zwischen dem Kontroller 12 und dem tat- 
sachlichen externen Funktionsblock 112 vorsieht. Nichtsde- 
stbweniger kann durch eine geeignete Operation des Schat- 
tenfunktionsblockes der Kontroller 12 den tatsachlichen 
Funktionsblock 112 steuern und mit diesem kommunizie- 
ren, so als ob dieser vollstandig in dem Kontroller 12 imple- 
mentiert ware. Indem beispiels weise eine Kommunikation 
mit dem Schattenfunktionsblock 108 durchgefuhrt wird, un- 
ter Verwendung des Kontrollerkonfigurationsprotokolls, 
kann die ProzeBsteuer- oder -regelroutine innerhalb des 
Kontrollers 12 auf den neuesten Stand gebrachte Informa- 
tionen von dem Funktionsblock 112 empfangen und kann 
Befehle zu dem Funktionsblock 112 so schneli wie moglich 
senden, ohne sich darum kummern zu miissen, wo der tat- 
sachliche Funktionsblock 112 gelegen ist Oder auf welche 
Weise Kommunikationen mit dem tatsachlichen Funktions- 
block 112 bewirkt werden. Statt dessen erfolgen die Kom- 
munikationen zwischen dem tatsachlichen Funktionsblock 
112 und dem Schattenfunktionsblock 108 automatisch ohne 
Eihgreifen durch die ProzeBsteuerroutine, die lediglich die 
Schritte ausfunren muB, die sie in typischer Weise ausfiihrt, 
urn die Kommunikationen zwischen den Steuer- oder Funk- 
tionsblocken zu implementieren, die innerhalb des Kontrol- 
lers 12 gelegen sind. In dieser Weise ermoglicht es der 
Schattenfunktionsblock einem Kontroller, der Funktions- 
blocke innerhalb des Kontrollers implemehtiert, Funktions- 
blocke zu verwenden und mit zu ihtegrieren, die unter- 
schiedliche Kommunikations- oder Konfigurationsproto- 
kolle verwenden und die nicht innerhalb des Kontrollers ge- 
legen sind, sondern die statt dessen in einer externen Vor- 
richtung gelegen und in diese ifnplementiert sind, wie bei- 
spiels weise einer mikroprozessor-unterstutzten Bereichs- 
vorrichtung, die in einer ProzeBumgebung angeordnet ist. 
Diese hinzugefiigte Fahigkeit.wird von dem Kontroller 12 in 
transparenter Weise erreicht, so daB dann, sobald der Schat- 
tenfunktionsblock in dem Kontroller 12 aufgebaut ist, die 
Steuer- oder Regelroutine nicht nachzusuchen braucht, wq 
der tatsachliche Funktionsblock gelegen ist, um komplexe 
Kommunikationen oder Datenbasismanipulationen durch- 
zufuhren, um den externen Funktionsblock 112 zu verwen- 
den. 

Wie hervorgeht, speichert der. Schattenfunktionsblock 
108 die EingangsgroBen und AusgangsgroBen der parame- 
trischen Updates, die dem AI-Funktionsblock 112 in einer 
Datenbasis in dem Kontroller 12 zugeordnet sind, und zwar 
in irgendeinem gewunschten Format, speichert jedoch in be- 
vorzugter Weise diese in dem gleichen oder einem ahnlichen 
Format wie die Informationen, die den Steuerblocken zuge^ 
ordnet sind, die durch den Kontroller implementiert sind, 



das heiBt unter Verwendung des Kon trollerkon figurations - 
protokolls. Dies macht die Kommunikation mit dem Schat- 
tenfunktionsblock 108 fur den Kontroller 12 transparent, 
das heiBt die ProzeBsteuer- oder -regelroutine 100 schafft 
5 eine Kommunikation in bezug auf den Schattenfunktions- 
block 108 (und somit mit dem tatsachlichen Funktionsblock 
. 112) uber die Verbindung in der gleichen Weise wie sie eine 
Kommunikation in bezug auf die anderen Funktionsblocke 
104 und 106 erzeugt. Wahrend es wianschenswert ist, daB 

10 die Funktionsblocke .innerhalb des Kontrollers 12 logisch 
konfiguriert sind, um all die Informationen (oder die mei- 
sten) zu untersttitzen, die durch das dezentralisierte oder ex- 
terne ProzeBregelnetzwerk uriterstutzt werden (wie dies bei 
dem Delta V-fcontroller und dem Fieldbus-Kommunikati- 

15 onsprotokoll der Fall ist), so ist diese Konfiguration nicht er- 
forderlich. Tatsachlich kann irgendein Kontrolleraufbau un- 
ter Verwendung des Schattenfunktionsblockes unterstiitzt 
werden, der hier offenbart ist, indem die Daten, die in dem 
externen Funktionsblock unterstiitzt werden und in diesem 

20 verfugbar sind, in den Daten abgebildet werden,. die in der 
Kontrollerroutine verwendet und verfugbar sind. 

Allgefnein gesagt, um den Betrieb des Schattenfunktions- 
blockes 108 in dem Fieldbus-Netzwerk zu bewirken, wird 
der tatsachliche Funktionsblock 112 so konfiguriert, um die 

25 ' verketteten Daten zu veroffentlichen und an den ProzeB kon- 
troller 12 (das heiBt die Daten, die mit einem anderen Block 
innerhalb des Kontrollers 12 uber eines der Verbindungs- 
glieder, die in Fig. 4 veranschaulicht sind, verbunden sind) 
oder zu. veroffentlichen, und zwar uber die Schnittstellen- 

30 karte 40, unter Verwendung des Veroffentlicher/Teilnehmer- 
VCR's (das heiBt synchronen Kommunikationen) in dem 
Fieldbus-Kommunikationsprotokoll. Andere nicht yerket- 
tete Daten, die dem tatsachlichen Funktionsblock 112 zuge- 
ordnet sind, werden an die Schnittstellenkarte 40 unter Ver- 

.35 wendung von asynchronen Kommunikationen bzw. Nach- 
richteniibertragungen . iibergeben, unter Verwendung • von 
beispiels weise den Betrachtungsobjekt- oder Warnobjekt- 
funktionen innerhalb des Fieldbus-Protokolls, was in der 
Modulabtastrate des Steuermoduls innerhalb des Kontrol- 

40 lers 12 stattfindet. Es werden daher in typischer Weise ver- 
kettete Daten zu dem Kontroller 12 von dem Funktions- 
block 112 in einer sehr viel schnelleren Rate gesendet als an- 
dere Daten (weniger zeitsensitive Daten). Umgekehft wer- 
den verkettete Daten, die durch einen Block innerfialb des 

45 Kontrollers 12 zu dem Schattenfunktionsblock 108 gesendet . 
werden, unmittelbar. an die Schnittstellenvorrichtung 40 
: weitergeleitet, wo sie auf dem Fieldbus-Bus 42 unter Ver- 
wendung von synchronen Standardnachrichtenubertragun- 
\ gen veroffentlicht werden. 

50 Die Informationen, die von dem tatsachlichen Funktions- 
block 112 gesendet werden, werden automatisch in den 
Schattenfunktionsblock 108 gesetzt und stehen somit fur die 
Steuer- oder Regelroutine in dem Kontroller 12 zu jeder Zeit 
zur Verfiigung. Um diese Operation zu bewirken, nimmt die 

55 Schnittstellenkarte 40 (die Teil eines Kommunikationsports 
des Schattenfunktionsblockes sein kann) teil an den verof- 
fentlichten Verbindungsparameterdaten, die durch den 
Funktionsblock 112 erzeugt wurden, und liefert diese Infor- 
mationen zu dem ProzeBkontroller 12 in der Rate, die durch 

60 die Ausfiihrungsrate des Funktionsblockes innerhalb des 
Makrozyklusses des Fieldbus-Segments festgelegt ist, an 
welches der externe Funktionsblock 112 angeschlossen ist. 
In alinlicher Weise erhalt die Schnittstellenkarte 40 (die ty- 
pischerweise das LAS des Fieldbus-Segments ist) die Be- 

65 'trachtungsobjekte und/oder Warnobjekte des tatsachlichen 
Funktionsblocks in einer Rate, die durch die Abtastrate des 
Kontrollermoduls festgelegt ist, in welchem der Schatten- 
funktionsblock 108 vorhanden ist, das heiBt in der Rate, in 
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welcher die Steuer- oder Regelroutine 100 in dem Kontrol- 
ler 12 die Blocke implementiert, die dieser zugeordnet sind. 
Wie dies bekannt ist, enthalt das Fieldbus-Protokoll vier Ty~ 
pen von Betrachtungsobjekten, die die normalerweise dyna- 
mischen (Betrachtungsobjekt 1), normalerweise statischen 5 
(Betrachtungsobjekt 2), alle dynaniischen (Betrachtungsob- 
jekt 3) und alle statischen (Betrachtungsobjekt 4) Variablen 
speichern. Die Schnittstellenkarte 40 ist so konflguriert, um 
automatisch auf einer periodischen Grundlage oder durch 
Aussenden einer Anfrage nach solchen Informationen das 10 
dynamische Betrachtungsobjekt 3 zu empfangen, welches 
die Werte fur alle die dynamischen Variablen enthalt, die 
dem tatsachlichen Funktionsblock 112 zugeordnet sind. 
Nach Empfangen dieser Betrachtungsobjektinformationen 
speichert die Schnittstellenkarte 40 die Informationen in ei- 15 
ner Datenbasis oder Datenbank, die durch den Schatten- 
funktionsblock zugreifbar ist, und der .Schattenfunktions- 
block 108 erneuert die Variablen, die sich dadurch geandert 
haben, wodurch diese variablen Werte fur die ProzeBsteuer- 
oder -regelroutine innerhalb des Kontrollers 12 verfugbar 20 
werden. Wenn eine der dynamischen Variablen (die stati- 
sche Revisionsvariable) eine Anderung an einer statischen 
Variablen anzeigt, kann der Schattenfunktionsblock oder die 
Software innerhalb der Schnittstellenkarte 40 anfragen, daB 
das Betrachtungsobjekt 4 (alle statischen Variablen) zu dem 25 
Schattenfunktionsblock 108 gesendet werden, um die stati- 
schen Variablen auf den neuesten Stand zu bringen. Bei der 
bevorzugten Ausfuhrungsform empfangt die HI -Schnitt- 
stellenkarte 40 fortlaufend das Betrachtungsobjekt 3 in der 
Modulabtastrate des Steuermoduls 100 innerhalb des Kon- 30 
trailers 12. 

Wie oben dargelegt ist, kann der Kontroller 12 (oder ir- 
gendein Funktionsblock desselben) Befehle zu dem aktuel- 
len Funktionsblock 112 innerhalb des Fieldbus-Netzwerks 
iiber den Schattenfunktionsblock 108 einfach dadurch sen- 35 
den, indem ein Parameter innerhalb des Schattenfunktions- 
blockes 108 geandert wird, Diese Parameteranderung wird 
automatisch nach unten zu dem AI-Funktionsblock 112 iiber 
einen Ausgang des Schattenfunktionsblockes 108 gesendet, 
wo er dazu verwendet wird, um die Konfiguration des AI- 40 
Funktionsblockes 112 zu andem. Wahrend die Datenande- 
rung oder der Einschreibbefehl in dem tatsachlichen Funk- 
tionsblock 112 nicht zu exakt der gleichen Zeit durchgefuhrt 
wird, zu der dieser durch den Schattenfunktionsblock 108 
.empfangen wird, und zwar vom Standpunkt des Kontrollers 45 
12 aus, erfolgt diese Anderung sehr schnell und wird in den 
Schattenfunktionsblock 108 zuriick reflektiert, wenn die 
Anderung tatsachlich vorgenommen wurde. Diese Betriebs- 
weise ermoglicht es dem Kontroller 12. und speziell dem 
PID-Funktionsblock 102, innerhalb des Kontrollers 12 eine 50 
Anderung zu bewirken, indem lediglich diese Anderung in 
eine Speicherstelle eingeschrieben wird, die dem Schatten- 
funktionsblock 108 zugeordnet ist und indem danach die 
Kommunikation automatisch vorgenommen wird, ohne daB 
dabei irgendwelche speziellen Kommunikationsaktivitaten 55 
ausgefuhrt werden miissen, die erforderlich sind, um Daten 
in das Fieldbus-Netzwerk hinein zu bekommen und heraus 
zu bekommen. 

Neben den Eingangs- und Ausgangsparameterdaten kon- 
nen andere Typen von Daten, wie beispielsweise Modus- 60 
und Statusdaten, zwischen einem Kontrollerfunktionsblock 
(das heiBt einem internen Funktionsblock) und dem Schat- 
tenfunktionsblock 108 ubertragen werden als auch zwischen 
dem Schattenfunktionsblock 108 und dem tatsachlichen ex- 
ternen Funktionsblock 112. Natiirlich wird diese Informa- 65 
tion mit den Betrachtungsobjekt- oder Warnobjektinforma- 
tionen von dem externen Funktionsblock 112 zu dem Schat- 
tenfunktionsblock 108 gesendet. In ahnlicher Weise konnen 
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solche Modus- und Statusdaten an den Schattenfunktions- 
block 108 von einem internen Funktionsblock innerhalb des 
Kontrollers 12 ubermittelt werden und es konnen diese Da- 
ten dann an den externen Funktionsblock 112 fur die Ver- 
wendung geliefert werden. Der Statusparameter eines Funk- 
tionsblockes zeigt in typischer Weise die Qualitat der Mes- 
sung oder der Daten an, die durch den Funktionsblock gelie- 
fert werden, und kann Grunde liefern, warum eine schlechte 
Qualitat existiert, Er kann auch eine Grenze anzeigen, wie 
beispielsweise eine hohe oder niedrige Grenze, welche die 
Daten erreichen konnen. Der Modusparameter zeigt in typi- 
scher Weise an, welcher Modus des Funktionsblocks einge- 
schaltet ist, welcher beispielsweise ein Handmodus, ein Au- 
tomatikmodus oder ein Kaskadenmodus sein kann, wie dies 
durch das Fieldbus-Protokoll festgelegt ist. 

Darliber hinaus wird eine Alarmdetektion basierend auf 
Alarmsignalen, die in dem tatsachlichen externen Funk- 
tionsblock erzeugt werden, vorgesehen, da Ereignisse und 
Berichte durch den externen Funktionsblock automatisch als 
dynamische Parameter erzeugt werden, die dann durch die 
Betrachtungs- oder Warnobjekte dem Schattenfunktions- 
block 108 angeboten werden. Als. ein Ergebnis kann eine 
Alarminforrnation, die den externen Funktionsblock betrifft, 
von dem Kontroller 12 betrachtet und verwendet werden. 

Obwohl natiirlich der Block 108 hier als Schattenfunkti- 
onsblock beschrieben wurde, konnen irgendwelche Blocke 
innerhalb der Fig. 4 ebenfalls oder alternativ Schattenfunk- 
tionsblocke sein. 

Die Vorteile, die mit der Verwendung eines Schattenfunk- 
tionsblockes verbunden sind, wie beispielsweise dem Schat- 
tenfunktionsblock 108, der in Fig. 4 veranschaulicht ist, be- 
stehen darin, daB dieser es dem ProzeBregeldesigner ermog- 
licht, die Steuerung oder Regelung innerhalb eines zentrali- 
sierten ProzeBkontrollers 12 zu. implementieren unter Ver- 
wendung von externen Funktionsblocken, das heiBt Funk- 
tionsblocken, die tatsachlich innerhalb einer verschiedenen 
Vorrichtung implementiert sind und die unterschiedlichen 
Kommunikationsprotokollen unterworfen sind. In Verbin- 
dung mit dem Schattenfunktionsblock braucht ein Designer 
oder Konstrukteur sich nicht darum zu kiimmern, daB der 
externe Funktionsblock einem unterschiedlichen Kommuni- 
kations- oder Steuer- oder Regelprotokoll zugeordnet ist 
oder in einer unterschiedlichen Vorrichtung gelegen ist, da 
die Nachrichteniibermittlung zwischen dem Schattenfunkti- 
onsblock und dem externen Funktionsblock automatisch er- 
folgt und auch transparent fur die Steuer- oder Regelroutine. 
Wenn ferner einmal ein Schattenfunktionsblock implemen- 
tiert ist und lauft, ist es einfach ein Modell dariiber zu erstel- 
len, was sich innerhalb des gesamten ProzeBregelsystems 
ereignet, und zwar ohne sich darum zu kummern, ob Aktio- 
, nen innerhalb einer Fieldbus- oder ahderen externen Vor- 
richtung auftreten oder innerhalb des Kontrollers auftreten, 
da der Schattenfunktionsblock fur den Kontroller und den 
Anwender bewirkt, daB es so scheint, daB der tatsachliche 
Funktionsblock in dem Kontroller implementiert ist, obwohl 
dies real nicht der Fall ist. - 

Wenn ein gemeinsamer Funktionsblocksatz und Schatten- 
funktionsblocke in dem Steuer- oder Regelsystem verwen- 
det werden, um Funktionsblocke wiederzugeben, die exter- 
nen Vorrichtungen zugeordnet sind, kann die Steuer- oder 
Regelstrategie zu Beginn ohne das Wissen ausgelegt wer- 
den, ob ein bestimmter Funktionsblock dieser Strategic in 
dem Steuer- oder Regelsystem vorhanden sein wird oder in 
einer externen Vorrichtung vorhanden sein wird, und es kon- 
nen Anwenderanwendungen auf die Schattenfunktions- 
blocke zugreifen (welche die externen Funktionsblocke wie- 
dergeben oder als Modell darstelien), und zwar in exakt der 
gleichen Weise wie sie auf die Steuer- oder Regelsystem- 
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funktionsblocke zugreifen. Auch werden Alarme, die durch 
die exteme Vorrichtung detektiert werden, voll in die Steu- 
ersysternalarmverarbeitung durch den Schattenblock inte- 
griert, mit der Moglichkeit, daB diese Alarme in exakt der 
gleichen Weise fur die externen Funktionsblocke erscheinen 
wie fur Funktionsblocke, die innerhalb des Steuer- oder Re- 
gelsystems vorhanden sind. . 

Die Konfiguration, Implementierung und Verwendung ei- 
nes Schattenfunktionsblockes wird nunmehr in Einzelheiten 
unter Hinweis auf die Fig. 5-13 beschrieben. Fig. 5 veran- 
schaulicht den physikalischen Aufbau eines Abschnitts des 
ProzeBregelnetzwerks von Fig. 1 mehr in Einzelheiten. Die 
Anwenderworkstation 150, die aus irgendeinem der PCs 14 
von Fig. 1 bestehen kann, ist kommunikativ mit dem Kon- 
troller 12 verbunden, der seinerseits uber die Schnittstellen- 
karte 40 mit der Bereichsvorrichtung 48 verbunden ist, wel- 
che den Funktionsblock 112 darin enthalt. Wie in Fig. 5 ver- 
anschaulicht ist, besitzt der Kontroller 12 einen oberen Ab- 
schnitt 152, in welchem die Steuerroutine 100 (ehthaltend 
den Schattenfunktionsblock 108) implementiert ist, und ei- 
nen.unteren Abschnitt, der eine Datenbasis oder Datenbank 
156 enthalt, urn Eingangs- und Ausgangsinformationen zu 
speichern, die von der Schnittstellenkarte 40 als auch von 
anderen I/O-Karten empfangen werden. AUgemein gesagt, 
ist die Schnittstellenkarte 40 so konfiguriert, urn automa- 
usch verkettete Daten zu empfangen, die durch den Funk- 
tionsblock 112 veroffentlicht werden, und zwar iiber den 
VerofYentlicher/Teilnehmer-VCR (In der Veroffentlichungs- 
rate, die durch den Makrozyklus des Fieldbus-Busses 42 
festgelegt ist), und um diese Daten in der unteren Datenbank 
156 zu speichern, wo sie dem Schattenfunktionsblock 108 in 
' der Abtastrate des Steuermodus 100 innerhalb des'Kontrol- 
lers 12 angeboten werden. In ahnlicher Weise ist die Schnitt- 
stellenkarte 40 so konfiguriert, um die verketteten Daten, die 
durch einen Funktionsblock innerhalb des Kontrollers 12 er- 
zeugt werden, auf dem Fieldbus-Bus 40 zu veroffentlichen, 
unter Verwendung synchroner Nachrichtenubermittlungen 
innerhalb des Fieldbus-Netzwerks. Auch ist die Schnittstel- 
lenkarte 40 so konfiguriert, um periodisch anzufragen nach 
(unter Verwendung asynchroner Nachrichteniibertragun- 
gen) Betrachtungs- und/oder Alarmdaten von dem Funk- 
tionsblock 112 und um diese Informationen in der unteren 
Datenbank 156 zu speichern, um sie an den Schattenfunkti- 
onsblock 108 in der Abtastrate des.Kontrollermoduls 100 zu 
liefern. 

Die Schnittstellenkarte 40 und/oder die Datenbasis 156 
kann einen Kommunikationsport des Schattenfunktions- 
blockes 108 umfassen, kann Teil von diesem sein oder kann 
durch diesen gesteuert sein, der Kommunikationen zwi- 
schen dem Schattenfunktionsblock 108 und dem externen 
Funktionsblock 112 implementiert. Der Kommunikations- 
port enthalt einen Eingang, der von dem externen Funk- 
tionsblock 112 Daten empfangt, und zwar unter Verwen- 
dung des Kommunikationsprotokolls des externen Funk- 
tionsblocks 112, und enthalt einen Ausgang, der mit dem ex- 
ternen Funktionsblock 112 in Verbindung steht, um Daten 
(inklusive Schreibbefehlen) an den externen Funktionsblock 
112 unter Verwendung des Kommunikationsprotokolls des 
externen Furiktionsblocks 112 zu senden, Naturlich kann der 
Kommunikationsport des Schattenfunktionsblocks 108 in 
der Software und/oder einer anderen Hardware in dem Kon- 
troller zusatzlich oder in Verbindung mit der Schnittstellen- 
karte 40 und der Datenbank 156 implementiert sein. 

Um eine Steuer- oder Regelroutine unter Verwendung ei- 
nes Schattenfunktionsblocks zu konfigurieren, kann ein An- 
wender bei der Workstation 150 irgendwelche Standard- 
werkzeuge verwenden, wie bei spiels weise solche, die durch 
das Delta V-Steuer- oder -Regelsystem geschaffen werden, 



um zu Beginn das ProzeGregelsystem zu konfigurieren. Im 
allgemeinen ermoglichen es die Delta V-Konfigurations- 
werkzeuge einem Anwender, Blocke darzustellen, zu konfi- 
gurieren und miteinander zu verbinden, wie beispielsweise 
5 diejenigen, die in Fig. 4 veranschaulicht sind, um eine oder " 
mehrere. Regelschleifen zu implementieren oder zu konstru- 
ieren oder Module, die der Steuer- oder Regelroutine zuge- 
ordnet sind. Zum Zwecke der Erlauterung kann die Steuer- 
routine zum Steuern eines Prozesses irgendeine Anzahl von 
10 Modulen enthalten, von denen jeder irgendeine Anzahl von 
gewiinschten Blocken enthalten kann, die eine Anzahl von 
Regelschleifen implementieren. Wahrend der Konfiguration 
oder der Konstruktion eines ProzeBregelrnoduls kann ein 
Anwender die Verwendung eines Funktionsblocks auswah- 
15 len, der innerhalb einer Vorrichtung extern zum Kontroller 
12 gelegen ist (wie beispielsweise einen Funktionsblock in- 
nerhalb einer der Fieldbus- Vorrichtungen des ProzeBregel- 
. systems). In diesem Fall kann das Konfigurationswerkzeug, •' 
welches dem Kontroller 12 zugeordnet ist, so konstruiert 
20 sein, um den Anwender zu fragen, die physikalischen der 
Verbindungen der Vorrichtung zu dem Kontroller 12 zu spe- 
zifizieren und andere Vorrichtungs- und Funktionsblock- 
konfigurationsinformationen zu spezifizieren, die fur die an-, 
fangliche Konfiguration der Vorrichtung und/oder des Funk- 
25 tionsblockes innerhalb der Vorrichtung gemaB dem Kom- 
munikationsprotokoll dieser Vorrichtung erforderlich sind 
(z. B. das Fieldbus-Kommunikationsprotokoll). Der An- 
wender kann dann aufgefordert werden, diese Informatio- 
nen in irgendeiner gewiinschten Weise. zu liefern, wie bei- 
30 spielsweise uber die Verwendung von Dialogkastcheri. Na- 
turlich hangt die exakte Information, die benotigt wird,. von 
dem TVP der Vorrichtung und des Funktionsblockes ab, der 
spezifiziert wird, wie dies von einem Fachmann in Verbin-' 
dung mit dem Vorrichtungsprotokoll, welches verwendet 
35 wird, wie beispielsweise dem Fieldbus-Protokoil, zu erken- 
nen ist. , 

Ein Weg, um zu spezifizieren, dafr ein Funktionsblock 
durch eine bestimmte exteme Vorrichtung (wie beispiels- 
weise eine Fieldbus- Vorrichtung) zu implementieren ist, be- 
40 steht darin, den Anwender dazu zu bringen, den Funktions- 
block, der innerhalb einer externen Vorrichtung gelegen ist, 
zu spezifizieren, unter Verwendung eines Browsers (oder ei- 
ner anderen Software) oder einer Liste oder durch Heraus- • 
greifen der externen Vorrichtungen, die an den Kontroller 
45 angeschlossen sind, und dann Auswahlen von einer der auf- , 
gelisteten externen Vorrichtungen als die Vorrichtung, in 
welcher der Funktionsblock zu implementieren ist. Ein an- 
derer Weg besteht darin, den Funktionsblock auf dem Bild- 
schirm auszuwahlen und dann diesen Funktionsblock auf 
50 eine Einzelheit eines Blocks in einer externen Vorrichtung 
durch Drag and Drop zu bewegen. Irgendeine dieser oder ir- 
gendeine andere gewiinschte Aktiori kann dem Konfigurati- 
.onswerkzeug mitteilen, daB der Funktionsblock, der imple- 
mentiert werden soli, innerhalb der externen Vorrichtung 
55 liegt, und kann das Konfigurationswerkzeug veranlassen, 
; den Anwender nach der spezifischen Vorrichtung und den 
Funktionsblockkonfigurationsinformationen zu fragen, die 
erforderlich sind, um den speziellen externen Funktions-- 
block zu konfigurieren und auf diesen zuzugreifen. Beide 
60 diese Verfahren ermoglichen es einem Anwender, einen 
Funktionsblock in einer externen Vorrichtung aus einer Li- 
ste von externen Vorrichtungen fur die Ausfuhrung eines 
Programms auszuwahlen. 

Wenn der Anwender spezifiziert, daB ein externer Funk- 
65 tionsblock zu verwenden ist (das heiBt extern vom Kontrol- 
ler 12),. so erstellt die Konfigurationsroutine dann einen 
Schattenfunktionsblock in dem Kontroller und unternimmt 
Schritte, um die Fieldbus- Vorrichtung und den Funktions- 
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block innerhalb der Vorrichtung zu konfigurieren, wie dies 
im folgenden beschrieben wird. Natiirlich erlaubt es das . 
Konfigurationswerkzeug in bevorzugter Weise dem Anwen- . 

, der, alle die Blocke, die zu verwenden sind, zu spezifizieren, 
ebenso die Ortlichkeiten oder Lagen solcher Blocke (das 
heiBt, ob irgendein Block in externen Vorrichtungen gelegen 
ist) und auch die Verbindungen zwischen den Blocken, be- 
vor die Schattenblocke implementiert werden und die exter- 
nen (z. B. Fieldbus-) Vorrichtungen initialisiert werden. Dies 
ermoglicht es, die Konfiguration des externen Netzwerks 
einmal auszufiihren, nach derri die Ortlichkeit oder Lage von 
alien den Blocken und auch die Natur von alien Verbindun- 
gen zwischen den Funktionsblocken spezifiziert worden ist. 

In Verbindung mit der Befahigung des Kontrollers, die 
Parameterdaten fur die Funktionsblocke innerhalb der exter- 
nen Vorrichtungen einzusehen oder Zugriff auf diese zu ha- 
ben (uber den Schattenfunktionsblock), kann die Schnitt- 

' stellenkarte 40 auch Vorrichtungs- und Segmentstatusinfor- 
mationen an den Kontroller fur Diagnosezwecke liefern. Die 
Schnittstellenkarte 40 kann beispielsweise eine Liste emp- 
fangen, die eine Identifikation der Vorrichtungen eiithalt, die 
angenornmenermaBen an einem bestimmten Abschnitt oder 
Segment des Fieldbus-Netzwerks angehangt oder ange- 
schlossen sind, und sachdienliche Informationen uber jede 
der identifizierten Vorrichtungen enthalten. Die Schnittstel- 
lenkarte 40 kann dann periodisch Informationen (uber syn- 
chrone oder asynchrone Nachrichtenverbindungen) erhal- 
ten, welche die Vorrichtungen betreffen, die tatsachlich an 
das Fieldbus-Segment angeschlossen sind oder die das Seg- 
ment selbst betreffen, und kann diese Informationen mit den 
Informationen innerhalb * der, empfangenen Liste vergiei- 
chen. Auf. diese Weise kann die Schnittstellenkarte 40 be- 
stimmen, ob die Bereichs vorrichtungen fehlen oder nicht an 
das Fieldbus-Netzwerk angeschlossen sind, ob falsche Be- 
reichsvorrichtungen an das Fieldbus-Netzwerk angeschlos- 
sen sind, ob eine Bereichsvorrichtung sich dem Service ent- 
zieht, usw. In ahnlicher Weise kann die Schnittstellenkarte 
40 bestirnmeh, ob Segmentwertprobleme auftreten, so als ob 
keine Nachrichten verbindung iiber den Fieldbus-Bus exi- 
stiert; Wenn es gewiinscht wird, kann die Schnittstellenkarte 
40 diese Vorrichtungs- und Segmentstatusdateh an den Kon- 
troller (oder andere Vorrichtung) fur Diagnosezwecke sen- 
den. 

Ferner kann die Schnittstellenkarte 40 die Kommunika- 
tion und den Zeitsteuerstatus eines Fieldbus-Segments fur 
Diagnosezwecke iiberwachen. Insbesondere kann die 
Schnittstellenkarte 40 automatisch an den Daten teilhaben, 
die durch die Bereichs vorrichtungen auf dem Fieldbus-Bus 
veroffentlicht werden, und kann die empfangenen Daten 
analysieren, um beispielsweise Zeitsteuerprobleme oder an- 
dere Probleme auf dem Fieldbus-Bus zu ermitteln. Wenn es 
gewiinscht wird, kann die Schnittstellenkarte 40 die ankom- 
menden Daten zeitlich pragen und speichern und dann Stati- 
stiken aufbewahren, die jedeh Funktionsb lock oder Vorrich- 
tung betreffen, der oder die an den Bus angeschlossen ist 
und/oder Statistiken aufbewahren, die das Segment des Bus- 
ses betreffen. Beispielsweise kann die Schnittstellenkarte 40 
die minimalen und maximalen Zeiten zwischen Datener- 
neuerungen bestimmen, und zwar fur bestimmte publizierte 
Daten, und kann bestimmen, ob diese Zeiten innerhalb eines 
zulassigen Bereiches liegen, um festzustellen, ob Kommuni- 
kationsprobleme existieren. In ahnlicher Weise kann die 
Schnittstellenkarte 40 die Zeiten, zu welchen bestimmte Da- 
ten angenornmenermaBen auf dem Bus zu veroffentUchen 
sind, mit der tatsachlichen Zeit vergleichen, zu welcher 
diese Daten auf dem Bus veroffentlicht werden, kann ver- 
brauchte Datenzahlwerte fur die Funktionsblocke oder Vor- 
richtungen iiberwachen und kann irgendwelche anderen ge- 



wiinschten Statistiken aufbewahren, um Zeitsteuerungs- 
oder andere Kommunikationsfehler auf dem Bus zu detek- 
tieren. Natiirlich konnen irgendwelche anderen publizierten 
Daten iiberwacht werden, um die Komrnunikations- oder 

5 Zeitsteuerprobleme auf dem Bus zu bestimmen. Wie oben 
dargelegt wurde, konnen die statistischen Informationen, die 
durch die Schnittstellenkarte 40 erzeugt oder gespeichert 
werden, fur irgendeinen Funktionsblock, Vorrichtung oder 
Segment des Busses aufbewahrt werden und konnen zu dem 

10 Kontroller (oder irgendeiner anderen Vorrichtung) fur Dia- 
gnosezwecke gesendet oder von dem Kontroller gelesen 
werden. 

Fig* 6 veranschaulicht ein FluBdiagramm 200, welches 
den Weg anzeigt, in welchem ein Schattenfunktionsblock 

15 innerhalb des Kontrollers 12 erstellt werden kann. Wahrend 
die RuBdiagramme der Fig. 6-12 eine Anzahl von Blocken 
veranschaulichen, sei darauf hingewiesen, daB diese Blocke 
lediglich eine Sequenz von Schritten angeben, die auszufiih- 
ren sind, und daB die Schritte in der Software oder in irgend- 

20 einer anderen gewiinschten Weise ausgefiihrt werden kon- 
nen. Die FluBdiagrammblocke der Fig. 6-12 stellen jedoch 
nicht notwendigerweise Funktionsblocke oder Kontroller- 
blocke dar, ahnliche den Funktionsblocken, die in Fig. 4 
veranschaulicht sind. - - 

25 Bei einem Block201 empfangt der Kontroller 12 ein Mo- 
dul-Installationsskript von der Anwenderwbrkstation, die 
auf einem der PCs 14 von Fig. 1 bestehen kann. Das Modul- ' 
Installationsskript wird durch das Konfigurationswerkzeug . 
erzeugt, welches durch die Anwenderworkstation ablauft 

30 oder auf dieser Anwenderworkstation lauft, und enthalt alle 
Informationen, die erforderlich sind, um die Objekte (in ei- 
ner objektorientierten Programmiersprache) zu erstellen, die 
den Funktionsblocken eines Steuermoduls in dem Kontrol- 
ler 12 zugeordnet sind. Das heiBt, das Installationsskript 

35 konflguriert die Blocke (wie beispielsweise die Funktions- 
blocke, die dem Steuermodul 100 von Fig. 4 zugeordnet 
sind) und die Verbindungen zwischen solchen Blocken, die 
durch die Verbindungen (Links) definiert sind. Naturlich 
werden all diese Informationen durch den Anwender gelie- 

40 fert, wahrend dieser das Konfigurationswerkzeug verwen- 
det. Wenn ein Funktionsblock durch einen externen Funk- 
tionsblock zu implementieren ist, wie beispielsweise einen 
in einer Bereichsvorrichtung, erzeugt ein Block J02 einen 
Schattenfunktionsblock innerhalb des Kontroller 12, und 

45 zwar durch Erzeugen eines Objektes (innerhalb einer ob- 
jektorientierten Programmiersprache), welches ahnlich ist 
den Funktionsblocken fur andere Vorrichtungen, die inner- 
halb des Kontrollers gelegen sind, ausgenommenen dieses 
fiihrt keinerlei Steuerfunktionen durch. Wahrend die Schat- 

50 tenfunktibnsblocke in bevorzugter Weise als ein Objekt in 
einer objektorientierten Programmierumgebung erzeugt 
werden, konnen sie unter Verwendung irgendeiner anderen 
Programmierumgebung erzeugt werden, die dem Kontroller 
12 zugeordnet ist oder von diesem verwendet wird. 

55 Wenn ein Schattenfunktionsblock aufgebaut wird, veran- 
laBt der Block 202 die Schnittstellenkarte 40, den tatsachli- 
chen Funktionsblock innerhalb der Fieldbus- Vorrichtung 
abzutasten und Informationen von dem tatsachlichen Funk- 
tionsblock zu erhalten, die erforderlich sind, um zu Beginn 

60 den Schattenfunktionsblock zu konfigurieren. Ferner erstellt 
der Block 202 die Datenbankstellen innerhalb der unteren 
Datenbank 156 des Kontrollers 12, an die die Schnittstellen- 
' karte 12 Betrachtungsobjekt- und Warnobjektdaten als auch 
verkettete Parameterdaten eingeben sollte, die von dem tat- 

65 sachlichen Funktionsblock erhalten werden. Der Block 202 
informiert auch die Schnittstelie 40 dariiber, wie oft Be- 
trachtungsobjekt- und Warnobjektinformationen basierend 
auf der Abtastrate des Moduls 100 angefragt werden sollen. 
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Nachdem der Block 202 einen Schattenfunktionsblock in 
dem Kontxoller erzeugt hat.und die geeigneteri Verbindun- 
gen zwischen der Datenbank 156, dem Schattenfunktions- 
block 108 und der Schnittstellenkarte 40 identifiziert hat, 
konfiguriert ein Block 203 die untere Datenbasis 156, um 
die gespeicherten verketteten Parameterdaten (das heiBt die- 

jenigen, die durch die Schnittstellenkarte 40 unter Verwen- 
dung des synchronen VeroffenthcherATeilnehmer-VCRs er- 
halten wurden) an den Schattenfunktionsblock zu liefern, 
anstelle der Daten, die fur die verketteten Parameter unter 
Verwendung der Objektoperation erhalten werden. Dies ist 
erforderlich, um sicherzusteilen, daB die zuletzt erstellten 
Daten fur die verketteten Parameter (das heiBt diejenigeri, 
die durch die synchronen Kommunikationen in dem Field- 
bus-Netzwerk erhalten wurden) dem Schattenfunktions- 
block 108 angeboten werden anstelle der Daten, die fur 
diese Parameter unter Verwendung der Betrachtungslisten- 
operation erhalten werden (was asynchron erfolgt); 

Wenn ein Steuermodul, der einen Schattenfunktionsblock 

. verwendet, zu Beginn konfiguriert wird, muB das Fieidbus- 
Kommunikationsnetzwerk ebenfalls konfiguriert werden, 
um die erforderlichen synchronen und asynchronen Nach- 
richtenubertragungen zwischen dem aktuellen Funktions- 

. bioc£ 112 und dem. Schattenfunktionsblock 108 zu unter- 
stiitzen. Die Fig.; 7-12 veranschaulichen RuBdiagramme, 
welche die Schritte herausgreifen, die beim Konfigurieren 
des Fieldbus-Netzwerks involviert sind, um die Schatten- 
funktionsblocke zu unterstiitzen. Wahrend die Fig. 7-10 als 
getrennte FluBdiagramme dargestellt sind, konnen sie 
gleichzeitig oder nahezu gieichzeitig ausgefuhrt werden. 

Fig. 7 zeigt ein FluBdiagramm 210, welches dazu ver- 
wendet werden kann, einen verbindungsaktiven Plan oder 
Ablaufsteuerung in dem Fieldbus-Netzwerk zu erstellen. 
Ein Block 211 innerhalb des Kontrollers 12 empfangt das 
LAS-Plan-Installationsskript, wie es durch das Konfigurati- 
onswerkzeug fur das Fieldbus-Kommunikationsnetzwerk 
entwickelt wurde, und zwar nach Inbetrachtziehung alier 
synchroner Nachrichtenubertragungen, die iiber den Field- 
bus-Bus stattfinden miissen, inklusive solcher, die fur die 
Schattenfunktionsblocke erforderlich sind. Natiirlich kann 
dieses- Installationsskript unter Verwendung bekannter 
Werkzeuge erzeugt werden, die fur das Fieldbus-Kommuni- 
kationsprotokoll verfugbar sind, die auch in dem Konfigura- 
tionswerkzeug des Kontrollers 12 integriert sein konnen. 
Ein Block 212 installiert dann den LAS-Plan (Abwickler) an 
dem angepeilten Fieldbus-Port, der beispielsweise die 
Schnittstellenkarte 40 aus Fig. 5 sein kann. 

Danach erzeugt ein Block 213 automatisch Teilnehmer- 
verbindungen und VCRs innerhalb des Fieldbus-Netzwerks 
basierend auf den Daten, die durch die Fieldbus-Vorrichtun- 
gen veroffentlicht werden. Speziell werden diese Teilneh- 
merverbindungen derart erzeugt, daB die Schnittstellenkarte 
40 teil hat an den verketteten Parametern der Fieldbus- 
Funktionsblocke, fur Schattenfunktionsblocke innerhalb des 
Kontrollers 12 existieren. In ahnlicher Weise gibt die 
Schnittstellenkarte 40 Daten heraus, die durch die Funk- 
tionsblocke innerhalb des Kontrollers 12 erzeugt werden 
und die zu den Schattenfunktionsblocken innerhalb des 
Kontrollers 12 als ein verketteter Parameter gesendet wer- 
den. AUgemein gesagt, agiert die Schnittstellenkarte 40 als 
ein Funktionsblock-Proxy fiir die verketteten Daten zu und 
von den Schattenfunktionsblocken. Ferner wirkt die Schnitt- 
stellenkarte 40 als ein Funktionsblock-Proxy, um nach Be- 
trachtungsobjekt- und Warnobjektinformationen von den 
tatsachlichen oder aktuellen Funktionsblocken anzufragen, 
fur welche Schattenfunktionsblocke existieren, um die nicht 
verketteten Daten zu erneuern, die den Schattenfunktions- 
blocken innerhalb des Kontrollers 12 zugeordnet sind. 



Ein Block 214 bildet dann den LAS-Installationsstatus in 
% dem Kontxoller (oder Delta V-)Status ab, so daB der Kontxol- 
ler 12 bestimmen kann, ob die LAS-Installation akzeptiert 
worden ist oder durch das Fieldbus-Netzwerk abgewiesen 
5 wurde. Dies ermoglicht es dem Kontxoller 12 zu verifizie- 
ren, ob die Installation des Fieldbus-Netzwerks stattgefun- 
den hat. 

Fig. 8 veranschaulicht ein FluBdiagramm 220, welches 
die Schritte zeigt, die dazu verwendet werden, um die Verof- 
10 fentlicher-Verbindungen innerhalb des Fieldbus-Netzwerks 
zu erstellen. Ein Block 221 in dem Kontroller 12 empfangt 
die Veroffentlicher-Verbindungen, die durch das Worksta- 
tion-Konfigurationswerkzeug fur das Fieldbus-Netzwerk er- . 
/ zeugt wurden, und ein Block 222 seridet dann diese Verof- 
15 fentlicher-Verbindungen (publisher links) zu der Schnittstel- 
lenkarte 40, um die Veroffentlicher-Verbindungen zu erstel- 
len und auch die zugeordneten VCRs, die erforderlich sind, 
um die Schattenrunktionsblockkommunikationen als auch 
andere Kommunikationen auf dem Funktionsblock 42 zu 
20 unterstiitzen. 

Fig. 9 zeigt ein FluBdiagramm 230, welches die Schritte 
veranschaulicht, die der Installation einer Vorrichtungskon- 
figuration innerhalb einer Fieldbus-Vorrichtung zugeordnet 
sind. Ein Block 231 empfangt das Vorrichtungskonfigurati- 
25 ons-Installationsskript von der Workstation, konfiguriert 
durch das Konfigurationswerkzeug, nachdem all die Verbin- . 
dungs- und anderen Informationen fur diese Vorrichtung er- 
stellt worden sind. Ein Block 232 loscht dann die fruhere 
Konfiguration in der Vorrichtung, indem sie geeignete Be- 
30 fehle zu der Vorrichtung iiber die Schnittstellenkarte 40 seh- 
det. Wahrend es nicht strikt erforderlich ist, wurde es als 
• wunschenswert gefunden, die fruhere Vorrichtungskonfigu- 
ration zu loschen, bevor versucht wird, eine neue Vorrich- 
tuhgskon figuration in der Fieldbus-Vorrichtung zu installie- 
35 ren, um dadurch Installation sprobleme zu vermeiden. 

Ein Block 233 installiert dann die VCRs und ein Block 
' 234 installiert die Verbindungen, die, erforderlich sind, um 
die Korrimunikation gemaB dem verbindungsaktiven Plan 
und die Veroffentlicher/Teilnehmerbeziehungen, die fiir das 
40 Fieldbus-Netzwerk erstellt wurden, zu implementieren. Ein 
Block 235 installiert dann die Fieldbus-Startliste in der Vor- 
richtung, was die Funktionsblock-Programmausfuhrung 
von dieser Vorrichtung mit der Programmausfuhrungen von 
anderen Funktionsblocken in anderen Vorrichtungen des 
45 Fieldbus-Netzwerks synchronisiert. Danach installiert ein 
Block 236 den Makrozyklus der Vorrichtung, nachdem die- 
ser Makrpzyklus berechnet worden ist oder bestimmte wor- 
den ist, um all den synchronen Kommunikationen Rech- 
nung zu tragen, die zwangs weise iiber den Bus 42 stattfin- 
50 den miissen, welcher dem Fieldbus zugeordnet ist. 

Fig. 10 zeigt ein FluBdiagramm 240, welches die Schritte 
veranschaulicht, die dazu verwendet werden, um einen spe- 
ziellen oder bestimmten Funktionsblock innerhalb einer be- 
stimmten Vorrichtung innerhalb des Fieldbus-Netzwerks zu 
55 erstellen. Ein Block 241 empfangt zuerst ein Funktions- 
block-Installationsskript, wie es durch das Konfigurations- 
werkzeug entwickelt wurde. Ein Block 242 installiert dann 
den nachsten Funktionsblock und Programmausfuhrungspe- 
riodenparameter, wie dies in typischer Weise vorgenommen , 
60 wird, wenn ein Fieldbus-Funktionsblock konfiguriert wird; 
Danach setzt ein Block 243 den Funktionsblockmodus au- 
Ber Service, was erforderlich ist, um die Werte innerhalb des 
Funktionsblockes zu andern. Ein Block 244 installiert dann 
die gemaB dem Funktionsblockparameter konfigurierten 
65 Werte oder die Anwenderprioritaten (overrides) (das heiBt 
die anwenderdefinierten Werte) innerhalb des Funktions- 
blockes. Diese durch den Anwender konfigurierten Werte, 
' konnen in irgendeiner Weise erstellt werden, wie beispiels- 
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weise durch die Verwendung von Dialogboxen in der Work- 
station wahrend der Konfiguration des ProzeBregelsy stems. 
Danach stellt ein Block 245 den Funktionsblockmodus auf 
den konfigurierten Wert ein, so daB der Funktionsblock in 
Einklang mit der Art arbeitet, in welcher dieser konfiguriert 
ist. z 

Es sei darauf hingewiesen, daB die FluBdiagramme der 
Fig. 7-9 lediglich die normalen Schritte angeben, die dazu 
verwendet werden, um ein Fieldbus-Netzwerk zu konfigu- 
rieren. In diesem Fall tragt jedoch die Erstellung des Field- 
.bus-Netzwerks Rechnung hinsichtlich der und enthalt die 
Veroffentlicher/Teilnehmerverbindungen und VCRs, die er- 
forderlich sind, um den Betrieb von irgendeinem der Schat- 
tenfunktionsblocke innerhalb des Kontrollers 12 zu unter- 
stiitzen. Natiirlich kann die Anwenderworkstation oder der 
Kontroller 12 das Fieldbus-Netzwerk automatisch konfigu- 
rieren, basierend auf den Informationen, die durch den An- 
wender iiber die Erstellung des Regelsy stems wahrend der 
Konfiguration dieses Systems geliefert werden. 

GemaB Fig., 11 veranschaulicht ein RuBdiagramm 250 
die Betriebs weise eines Schattenfunktionsblockes, wenn ein 
Steuermodul, der diesen Schattenfunktionsblock enthalt, auf 
dem Kontroller 12 lauft, um die ProzeBsteuerung oder -rege- 
lung durchzufiihren. Wie zu erkennen ist, implementiert der 
Kontroller 12 die Blocke innerhalb eines bestimmten Mo- 
duis (wie beispiels weise die Blocke 102, 104, 106 und 108 
von Fig. 4) in der Modulabtastrate, die dem Modul zugeord- 
net ist. Die Kommunikation von verketteten Daten (wie den- 
jenigen, die durch die Verbindungen in dem Diagramm von 
Fig. 4 definiert sind) zwischen den aktuellen Fieldbus-Funk- 
tionsblocken und den Schattenfunktionsblocken erfolgt in 
der synchronen Makrozyklusrate des Fieldbus-Netzwerks, 
die verschieden sein kann von der Modulabtastrate des Kon- 
trollers 12. Als ein Ergebnis werden die Daten fiir die ver- 
ketteten Parameter in typischer Weise in der unteren Daten- 
bank 156 des Kontrollers 12 in einer unterschiedlichen (ge- 
wohnlich schnelleren) Rate als die Daten fur nicht verkettete 
Parameter gespeichert. 

Wenn der Schattenfunktionsblock in dem Kontroller 12 
. implementiert ist, tastet ein Block 252 die Betriebsdaten ab, 
die innerhalb der unteren Datenbank 156 des Kontrollers 12 
gespeichert. sind. Das heiBt, es werden wahrend jeder Mo- 
dulperiode die Betriebsdaten, die in der unteren Datenbank 
156 gespeichert wurden, durch den Schnittstellenmodul 40 
gelesen. Ein Block 254 ermittelt, ob die Abtastung voran- 
schreitet, Wenn dies nicht der Fall ist, erneuert ein Block 
256 den Blockfehler in dem Schattenfunktionsblock, stellt 
den Schattenfunktionsblock-Ausgangsstatus auf schlecht 
ein und stellt die Port-Integritat so ein, um dem Kontroller 
12 anzuzeigen, daB der Schattenfunktionsblock ausgef alien 
ist und daB daher ein Problem in bezug auf den externen 
Funktionsblock. oder in bezug auf Nachrichtenubertragun- 
gen mit dem externen Funktionsblock innerhalb des Field- 
bus-Netzwerks auftreten kann. Wenn solch ein Fehler detek- 
tiert wird, werden die Schattenfunktionsblockdaten nicht er- 
neuert (da diese Daten alt sind oder in jedem Fall schlechte 
Daten sind) und es wird die Erneuerungsoperation der Daten 
innerhalb des Schattenfunktionsblocks fur diesen Modulab- 
tastzyklus angehalten. Wenn jedoch die Abtastung voran- 
schreitet, kopiert ein Block 258 die empfangenen Betriebs- 
daten in dem Schattenfunktionsblock. Natiirlich enthalten 
die Betriebsdaten nicht nur die Daten, die durch die Betrach- 
tungs- und Warnobjekte in der Modulabtastrate erhalten 
werden, sondern auch die Daten fur die verketteten Parame- 
ter, die erhalten wurden und in die untere Datenbank 156 in 
einer Rate eingeschrieben werden, die durch den Makrozy- 
klus des Fieldbus-Netzwerks festgelegt wird. 

Ein Block 260 ermittelt dann, ob der statistische Revisi- 
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.- onsparameter, der dem tatsachlichen Funktionsblock zuge- 
ordnet ist (der durch die Betrachtungsobjektoperation gelie- 
fert wird) zugenommen hat. Wenn dies der Fall ist, instruiert 
ein Block 252 die Schnittstellenkarte 40, die statischen Da- 

5 ten, die dem Fieldbus-Funktionsblock zugeordnet sind,- zu 
lesen und diese statischen Daten zu der unteren Datenbank 
156 zu liefern, wo diese Daten gelesen werden und in den 
Schattenfunktionsblock eingesetzt werden. Wie dies be- 
kannt ist, zeigt der statische Visionsparameter an, ob irgend- 

10 welche statischen Dateri, die norrnalerweise durch die stati- 
sche Betrachtungsliste vorgesehen werden, geandert wur- 
den. Wenn der statische Revisionsparameter nicht erhoht . 
wurde, werden keine der statischen Daten geandert und es 
ist nicht erforderlich, diese Daten wahrend jedes Zyklusses 

15 des Steuermoduls zu lesen. Wenn jedoch die statische Da- 
tenrevision zugenommen hat, dann haben sich einige der . 
statischen Daten geandert und es miissen diese statischen 
Daten gelesen werden und in den Schattenfunktionsblock 
gesetzt werden, so daB der Schattenfunktionsblock die Da- 

20 ten spiegelt, die tatsachlich innerhalb . des externen Funk- 
tionsblocks vprhanden sind. 

Nachdem die statischen Daten erhalten worden sind oder 
die statische Revision nicht zugenommen hat, bildet ein , 
Block 264 die'Fieldbus-Alarme (und andere Daten, wenn 

25 dies erforderlich ist) in den Alarmen (oder anderen Datenbe- 
reichen) des Kontrollers 12 ab. Diese Abbildung kann unter 
Verwendung einer Nachschlagetabelle erreicht werden oder 
durch irgendeine andere Abbildungstechnik. Die abgebilde- 
ten AlarmgroBen (und andere Daten) werden dann 'in dem 

30 Schattenfunktionsblock gespeichert, um durch andere Steu- 
erblocke des Steuermoduls verwendet zu werden. Die 
AlarmgroBen konnen auch fur einen Anwender dargestellt 
werden oder in irgendeiner anderen gewiinschten Weise ver- 
wendet werden. 

35 Danach ermittelt ein Block 266, ob die Daten fiir die ver- 
ketteten Parameter veraltet sind (das heiBt nicht mehr aktu- . 
ell sirid). Solch eine Anzeige wird in regularer Weise in den 
FieldbusrKommunikationen erzeugt und sie zeigt an, daB 
die empfangenen Daten nicht in dem allerletzten Makrozy- . 

40 klus des Fieldbus-Netzwerks erzeugt wurden, was anzeigen 
kann, daB ein Zeitsteuerproblem oder ein anderes Problem 
innerhalb des Fieldbus-Netzwerks existieren kann. Wenn 
die Verkettungsparameterdaten veraltet sind, markiert .ein 
Block 268 die Ausgangsdaten als BadNotConnected, was 

45 den Modus oder Status von anderen Funktionsblocken in- 
nerhalb des Kontrollers 12 andern kann. Danach oder wenn 
die verketteten Daten nicht veraltet sind, macht ein Block 
270 die Betriebsdaten fiir andere Blocke innerhalb des Kon- 
trollers 12 sichtbar und der Kontroller 12 fahrt damit fort, 

50 basierend auf den neuen Betriebsdaten zu arbeiten. 

Wie ersehen werden kann, veranschaulicht das RuBdia- 
gramm von Fig. ll die Betriebs weise der Erneuerung des 
Schattenfunktionsblocks, um sicherzustellen, daB dieser die 
Daten spiegelt, die dem externen Funktionsblock innerhalb 

55 einer externen Vorrichtung zugeordnet sind. Jedoch kann 
der Schattenfunktionsblock auch Daten zu dem externen 
•Funktionsblock ubertragen und Schreibbefehle an den exter- 
nen Funktionsblock senden. Solche Daten und Schreibbe- 
fehle konnen von einem Anwender, beispielsweise bei einer 

60 Workstation, vorgesehen werden oder konnen an anderen - 
Funktionsblocken innerhalb des Kontrollers 12 entspringen 
und von diesen ausgesendet werden, und zwar uber die er- 
stellten Verbindungen. GemaB Fig. 12 veranschaulicht ein 
RuBdiagramm 280 die Schritte, die unternornmen werden, 

65 um Daten oder Schreibbefehle zu einem externen Funk- 
tionsblock iiber den Schattenfunktionsblock zu senden. Bei 
einem Block 281 schreibt ein Steuerblock innerhalb des 
Kontrollers 12 Daten iiber eine Eingangsvefbindung in den 
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Schattenfunktionsblock ein. Alternativ kann ein Anwender 
einen Schreibbefehl an den Schattenfunktionsblock uber 
eine Anwenderschnittstelle senden, was es einem Anwender 
ermoglicht, z. B. von Hand einen Sollwert oder einen ande- 
ren Wert, der dem externen Funktionsblock zugeordnet ist, 
zu andern. Der Schattenfunktionsblock sendet dann unmit- 
telbar einen Schreibbefehl oder andere Daten an die Schnitt- 
stellenkarte 40. Wenn solche Daten oder Befehl einem ver-* 
ketteten Parameter zugeordnet sind oder ist, veroffentlicht 
die Schnittstellenkarte 40 die Daten auf dem Fieldbus-Bus 
fur den externen Funktionsblock zu einem geeigneten oder 
synchronen Zeitpunkt, wie dieser durch den Makrozyklus 
des Fieldbus.-Netzwerks festgelegt ist. Wenn der Schreibbe- 
fehl oder die Daten nicht einem verketteten Parameter zuge- 
ordnet ist bzw. sind, verwendet die Schnittstellenkarte 40 
asynchrone NachrichtenUbertragungen, um den Befehl oder 
die Daten an den externen Funktionsblock ZU' ubermitteln. 
Danach empfangt der externe Funktionsblock die Daten 
oder den Befehl und erneut deren oder dessen Attributpara- 
meter entsprechend. Diese Anderungen werden dann uber 
die Schnittstellenkarte 40 unter Verwendung von Veroffent- 
licher/Teilnehmer-Kommunikadonen zuriick ubertragen, als 
auch die Betrachtungsobjektoperation, und es werden die 
neuen Daten in die untere Datenbank 156 gesetzt, wo dann 
wahrend des nachsten Abtastzyklusses des Steuermoduls 
diese Daten in den Schattenfunktionsblock eingesetzt wer- 
den. 

Wenn der Block 282 eine Schreibanfrage an die Schnitt- 
stellenkarte 40 sendet und diese Anfrage zu dem externen 
Funktionsblock gesendet wird, empfangt die Schnittstellen- 
karte 40 eine Antwort von dem Funktionsblock, die anzeigt, 
ob der Schreibvorgang vervollstandigt worden ist oder ob 
clie Daten angenommen oder empfangen wurden. Die 
Schnittstellenkarte 40 sendet ihrerseits diese Antwort zu 
dem Schattenfunktionsblock. Wenn der Schreibvorgang 
fehlgeschlagen ist, kann die Status-, Alarm- oder Fehlerein- 
stellung des Schattehfunktionsblocks geandert werden, um 
diesen Fehler zu reflektieren. Wenn beispielsweise eine 
. Schreibanfrage, die einem verketteten Parameter zugeordnet 
ist, nicht empfangen wurde oder nicht richtig durch die 
Schnittstelle 40 implementiert wurde, kann dies in demFeh- 
lerstatus des Schattenfunktionsb locks angezeigt werden. 
Wenn es gewiinscht wird, wenn ein Schreibbefehl, der von 
einem Anwender stammt, fehlschlagt, implementiert zu 
werden, kann ein Block 283 eine Anzeige uber den Fehl- 
schlag fur den Anwender bei der Workstation senden oder 
zu irgendeiner anderen Anwenderschnittstelle, um dadurch 
den Anwender uber den fehlgeschlagenen Versuch zu unter- 
richten, in den externen Funktionsblock zu schreiben. 

Wahrend sich die Beschreibung auf die Implementierung 
und die Verwendung eines einzelnen Schattenfunktions- 
blockes 108 gerichtet hat, sei darauf hingewiesen, daB viele 
Schattenfunktionsblocke in dem gleichen Steuermodul oder 
Kontroller implementiert werden konnen, um es dem Steu- 
ermodul oder Kontroller zu ermoglichen, viele externe 
Funktionsblocke zu verwenden. Ferner konnen Schatten- 
funktionsblocke implementiert werden unter Verwendung 
irgendeines externen ProzeBsteuer- oder -regel-Kommuni- 
kationsprotokolls (neben dem Fieldbus-Protokoll) und kon-r 
nen dazu verwendet werden, mit irgendeiriem Typ eines 
Funktionsblocks zu kommunizieren, inklusive irgendeinem 
Funktionsblock, der ahnlich ist mit oder der gleiche ist wie 
irgendeiner der unterschiedlichen Funktionsblocke, die 
durch das Fieldbus-Protokoll spezifisch identifiziert und un- 
terstutzt werden. Obwohl darliber hinaus Schattenfunktions- 
blocke hier so beschrieben wurden, als ob sie einem exter- 
nen Funktionsblock zugeordnet sind, und zwar in der Form, 
in welcher das Fieldbus-Protokoll einen "Funktionsblock" 



definiert, sei darauf hingewiesen, daB die Verwendung des 
Ausdrucks "Funktionsblock" hier nicht auf das beschrankt 
ist, was das Fieldbus-Protokoll als einen Funktionsblock de- 
finiert, sondern statt dessen irgendein anderer Typ eines 

5 Blocks, Programms, einer Hardware, Firmware usw. enthal- 
ten ist, die mit irgendeinem Typ eines Steuersystems oder 
Regelsysterns und/oder Kommunikationsprotokoll zugeord- 
net ist und die dazu verwendet werden kann, um eine ge- 
wisse Steuerfunktion oder Regelfunktion zu implementie- 

10 ren. Obwohl somit Funktionsblocke typisch die Form von 
Objekten annehmen, und zwar innerhalb einer objektorien- 
tierten Programmierumgebung, muB dies nicht der Fall sein 
und statt dessen konnen andere logische Einheiten dazu ver- 
wendet werden, um eine bestimmte Steuerung oder Rege- 

15 lung (inklusive Eingabe- und Ausgabe-)Funktionen inner- 
halb einer ProzeBsteuefumgebung oder ProzeBregelumge- 
bung auszufuhren. 

Obwohl ferner der Schattenfunktionsblock, der hier be- 
schrieben wurde, in bevorzugter Weise in einer Software 

20 implementiert wird, die beispielsweise in einem Kontroller 
oder einer anderen PrpzeBsteuervorrichtung gespeichert ist, 
' kann sie alternativ oder zusatzlich in einer Hardware, Firm- 
ware usw. in gewiinschter Weise implementiert sein. Wenn 
sie in einer Software implementiert ist, kann der Schatten- 

25 funktionsblock der vorliegenden Erfindung in irgendeinem 
computerlesbaren Speicher gespeichert sein, wie beispiels- 
weise einer Magnetplatte, einer Laserplatte oder einem an- 
deren Speichermedium, in einem RAM oder ROM eines 
Computers usw. In ahnlicher Weise kann diese Software an 

30 einen Anwender oder eine Vorrichtung aus geliefert werden, 
und zwar uber irgendein bekanntes oder gewiinschtes Aus- 
lieferungsverfahren, inklusive beispielsweise uber einen 
Nachrichtenubertragungskanal, wie beispielsweise eine Te- 
lefohleitung, das Internet usw. 

35 Obwohl auch der Schattenfunktionsblock der vorliegen- 
den Erfindung in Einzelheiten in Verbindung mit einem Pro- 
zeBregelnetzwerk beschrieben wurde, welches die ProzeB- 
steuerfunktionen in einer dezentralisierten oder verteilten 
Weise unter Verwendung eines Satzes von Fieldbus-Vor- 

40 richtungen implementiert, sei darauf hingewiesen, daB der 
Schattenfunktionsblock der vorliegenden Erfindung in Ver- 
bindung mit ProzeBregelnetzwerken verwendet werden 
. kann, die Steuerfunktionen ausfuhren, unter Verwendung 
von anderen Typen von Bereichs vorrichtungen und Kom- 

45 munikationsprotokollen, inklusive der Prot'okolle, die auf 
anderen als den zwei Leitungsbussen basieren, und Proto- 
kollen, die analog und/oder digitaie Nachrichteniibertragun- 
gen unterstiitzen. Der Schattenfunktionsblock def vorliegen- 
den Erfindung kann beispielsweise in irgendeinem ProzeB- 

50 regelnetzwerk verwendet werden, welches Vorrichtungen 
verwendet, die in Einklang mit dem HART-, PROFEBUS-, 
usw. Kommunikationsprotokollen oder irgendeinem ande- 
ren Kommunikationsprotokoll stehen, die es riunmehr gibt 
oder die in der Zukunft entwickelt werden konnen. In ahnli- 

55 cher Weise kann, wenn dies gewunscht wird, der Schatten- 
' funktionsblock der vorliegenden Erfindung in ProzeBregel- 
netzwerken verwendet werden, die keine verteilten Steuer- 
funktionen haben, sondern statt dessen einen zentralisierten 
Kontroller oder ein Steuer- oder Regelschema verwenden, 

60 um die Vorrichtungen darin zu steuern oder zu regeln. - . 
Wahrend die vorliegende Erfindung in bezug auf spezifi- 
sche Beispiele beschrieben wurde, die dazu dienen, die Er- 
findung lediglich zu veranschaulichen, jedoch nicht einzu- 
schranken, ist es fur Fachleute offensichtlich, daB Anderun- 

65 gen, Erganzungen oder Weglassungen bei den offenbarten 
Ausfuhrungsformen vorgenommen werden konnen, ohne 
dadurch die Idee und den Rahmen der vorliegenden Erfin- 
dung zu verlassen. 
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Patentanspriiche 

1. Interface-Funktionsblock fur die Verwendung in ei- 
nem ProzeB kontroller, der kommunikativ mit einer ex- 
ternen Vorrichtung iiber ein Kommunikationsnetzwerk 5 
gekoppelt ist, wobei der ProzeBkontroiler folgendes 
implementiert: 

- eine Steuerroutine unter Verwendung eines in- 
ternen Funktionsblockes, welcher innerhalb des 
ProzeBkontrollers angeordnet ist, und 10 

- einen externen Funktionsblock, der in der ex- 
ternen Vorrichtung angeordnet ist, wobei der In- 
terface-Funktionsblock folgendes aufweist: 

- einen Kommunikationsport mit einem Eingang, 
der mit dem externen Funktionsblock iiber das 15 
Kommunikationsnetzwerk. kommuniziert, um Da- 
ten, die den externen Funktionsblock betreffen, zu 
empfangen, und 

- einen Speicher, der die empfangenen Daten, die 
den externen Funktionsblock betreffen, gemaB ei- 20 
nem Kommunikationsprotokoll des internen . 
Funktionsblockes speichert. 

2. Interface-Funktionsblock nach Anspruch 1, der fer- 
ner einen Ausgang umfaBt, der die Daten, die den ex- 
ternen Funktionsblock betreffen, an den internen Funk- 25 
tionsblock gemaB dem Kommunikationsprotokoll des 
internen Funktionsblockes liefert. 

3. Interface-Funktionsblock nach Anspruch 2, bei dem 
der Eingang des Kommunikationsports die Daten, die . 
den externen Funktionsblock betreffen, unabhangig 30 
von der Operation des internen Funktionsblockes emp-' 
fangt. 

4. Interface-Funktionsblock nach Anspruch 2, bei dem 
der externe Funktionsblock iiber das Kommunikations- 
netzwerk unter Verwendung eines ersten Kommunika- 35 
tionsprotokolls kommuniziert, welches yerschieden ist 
von einem zweiten Kommunikationsprotokoll, das 
dem Konfigurationsprotokoll des internen Funktions-t 
blockes zugeordnet ist und bei dem der Eingang des 
Kommunikationsports mit dem externen Funktions- 40 
block unter Verwendung des ersten Kommunikations- 
protokolls kommuniziert und der Ausgang mit dem in- 
ternen Funktionsblock gemaB dem zweiten Kommuni- 
kationsprotokoll kommuniziert. 

5. Interface-Funktionsblock nach Anspruch 4, bei dem 45 
das erste Kommunikationsprotokoll ein Fieldbus- 
Kornmunikationsprotokoll ist und bei dem der Eingang 
des Kommunikationsports mit dem externen Funk- 
tionsblock unter Verwendung des Fieldbus-Kommuni- 
kationsprotokolls kommuniziert. 50 

6. Interface-Funktionsblock nach Anspruch 5, bei dem 
der Eingang des Kommunikationsports eine Schnitt- 
stellenvorrichtung verwendet, die konfiguriert ist, um 
mit der externen Vorrichtung unter Verwendung des 
Fieldbus-Kommunikationsprotokolls zu kommunizie- 55 
ren, um mit dem externen Funktionsblock zu kommu- 
nizieren. 

7. Interface-Funktionsblock nach Anspruch 1, bei dem 
der Kommunikationsport mit dem externen Funktions- 
block unter Verwendung synchroner Nachrichtenuber- 60 
tragungen kommuniziert. 

8. Interface-Funktionsblock nach Anspruch 1, bei dem 
• der Kommunikationsport mit dem externen Funktions- 
block unter Verwendung synchroner und asynchroner 
Nachrichteniibertragungen kommuniziert. 65 

9. Interface-Funktionsblock nach Anspruch 1, bei dem 
die externe Vorrichtung unter Verwendung eines Vor- 
richtungskommunikationsprotokolls Nachrichten iiber- 
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mittelt, welches die Kommunikation von logisch ver- 
ketteten Paketen von Daten unter Verwendung von 
standardisierten Kommunikationsanrufen unterstutzt 
und bei dem der Kommunikationsport mit dem exter- 
nen Funktionsblock unter Verwendung der standardi- 
sierten Kommunikationsanrufe kommuniziert, die dem 
Vorrichtungskommunikationsprotokoll zugeordnet 
sind. 

10. Interface-Funktionsblock nach Anspruch 9, bei 
dem das Vorrichtungskornmunikationsprotokoll ein 
Fieldbus-Kommunikationsprotokoll ist und bei dem 
der Kommunikationsport mit der externen Vorrichtung 
unter Verwendung von Betrachtungsobjekten innerhalb 
des Fieldbus-Kommunikationsprotokolls kommuni- 
ziert, 

11. Interface-Funktionsblock nach Anspruch 1, bei 
dem der Kommunikationsport eine Alarmanzeige von 
dem externen Funktionsblock ernpfangt und bei dem 
der Speicher die empfangene Alarmanzeige speichert. 

12. Interface-Funktionsblock nach Anspruch 1, bei 
dem der Kommunikationsport ferner einen Ausgang 
enthalt, welcher Daten zu dem externen Funktions- 
block unter Verwendung eines Kommunikationsproto- 
kolis sendet, welches dem externen Funktionsblock zu- 
geordnet ist. 

13. Kontroller, der dafur ausgebildet ist, um kommuni- 
kativ an eine Vielzahl von Bereichsvorrichtungen ge- 
koppelt zu werden, wobei eine der Bereichsvorrichtun- 
gen einen externen Funktionsblock enthalt, der unter 
Verwendung eines Vorrichtungskommunikationsproto- 
kolls Nachricht ubertragt, wobei der Kontroller folgen- 
des aufweist: 

einen Prozessor; 
einen Speicher; und 

eine Steuerroutine, die in dem Speicher gespeichert ist 
und durch den Prozessor implementiert wird, um die 
Vielzahl der Bereichsvorrichtungen zu steuern, wobei 
die Steuerroutine folgendes enthalt: 

- eine Vielzahl von miteinander verbundenen in- 
ternen Funktionsblocken, die so konfiguriert sind, 
um ein Kontrollerprotokoll zu verwenden und 
durch den Kontroller implementiert sind, und 

- einen Interface-Funktionsblock, der mit einer 
der Vielzahl der miteinander verbundenen inter- 
nen Funktionsblocke unter Verwendung des Kon- 
trollerprotokolls kommuniziert, und der mit dem 
externen Funktionsblock innerhalb einer der Be- 
reichsvorrichtungen unter Verwendung des Vor- 
richtungskommunikationsprotokolls kommuni- 
ziert, wobei der Interface-Funktionsblock Daten 
speichert, die den externen Funktionsblock betref- 
fen, welche von dem externen Funktionsblock 
empfangen wurden. 

14. Kontroller nach Anspruch 13, bei dem der Inter- 
face-Funktionsblock die Daten, die den externen Funk- 
tionsblock betreffen, unabhangig von der Operation 
der Vielzahl der internen Funktionsblocke ernpfangt. 

15. Kontroller nach Anspruch 13, bei dem das Vor- 
richtungskommunikationsprotokoli ein Fieldbus-Kom- 
munikationsprotokoll ist und bei dem der Interface- 
Funktionsblock mit dem externen Funktionsblock un- 
ter Verwendung des Fieldbus-Kommunikationsproto- 
kolls kommuniziert. 

16. Kontroller nach Anspruch 15, bei dem der Inter- 
face-Funktionsblock mit dem externen Funktionsblock 
unter Verwendung von Betrachtungsobjekten innerhalb 
des Fieldbus-Kommunikationsprotokolls kommuni- 
ziert. 
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17. Kontroller nach Anspruch 15, bei dem der Inter- 
face-Funktionsblock mit dem externen Funktionsblock 
unter Verwendung von Teilnehmer /Herausgeber- 
Nachrichteniibertragungen innerhalb des Fieldbus- 
Kommunikationsprotokolls kommuniziert. . 5 

18. Kontroller nach Anspruch 13, bei dem der Inter- 
face-Funktionsblock Daten, welche die Eingangsgro- 
Ben und AusgangsgroBen des externen Funktionsblok- 
kes betreffen, empfangt und speichert. 

19. ' Kontroller nach Anspruch 13, bei dem der Inter- 10 
face-Funktionsblock Daten, die AlarmgroBen betref- 
fen, welche durch den externen Funktionsblock erzeugt 
wurden, empfangt und speichert. 

20. Kontroller nach Anspruch 13, bei dem der Inter- 
face-Funktionsblock Daten, die den Modus des exter- 15 
nen Funktionsblockes betreffen, empfangt und spei- 
chert. 

21. Kontroller nach Anspruch 13, bei dem der Inter- 
face-Funktionsblock Daten, die durch eine der Vielzahl 
der internen Funktionsblocke erzeugt wurden, zu dem 20 
externen Funktionsblock sendet. 

22. Kontroller nach Anspruch 13, bei dem der Inter- 
face-Funktionsblock einen Befehl, der durch den Kon- 
troller erzeugt wurde, zu dem externen Funktionsblock 
sendet. ■ 25 

23. Verfahren zum Implementieren einer Steuer- oder 
Regelroutine in einem ProzeBkontroller, der kommuni- 
kativ mit einer Bereichsvorrichtung gekoppelt ist, wo- 
bei die Bereichsvorrichtung einen externen Funktions- 
block aufweist, der in ihr angeordnet ist und unter Ver- 30 
wendung eines Vorrichtungskommunikationsproto- 

. kolls Nachrichten ubertragt, wobei das Verfahren die 
folgenden Schritte umfaBt: 

- Speichern einer Vielzahl von miteiriander ver- 
bundenen internen Funktionsblocken in dem Kon- 35 
troller, der.gemaB einem Kontrollerprotokoll kon- 
figuriert istj um diese als Teil der Steuer- oder Re- 
gelroutine zu implementieren; 

- Erzeugen eines Interface-Funktionsbloekes in- 
nerhalb des Kontrollers, der gemaB dem Kontrol- 40 . 
lerprotokoll konfiguriert ist, wobei der Interface- 
Funktionsblock mit dem externen Funktionsblock 
unter Verwendung des Vorrichtungskommunikati- 
onsprotokolls kommuniziert; 

t- Erzeugen einer Steuer- oder Regelroutine, wel- ' 45 
che die Vielzahl der miteinander verbundenen in- 
' ternen Funktionsblocke und den Interface-Funk- 
tionsblock verwendet, um den ProzeB zu steuern 
oder zu regeln; und 

- Speichern von Daten in dem Interface-Funk- 50 
tionsblock wahrend der Implementierung der 
Steuer- oder Regelroutine, die dem externen 
Funktionsblock zugeordnet sind und von diesem 
empfangen werden. 

24. Verfahren nach Anspruch 23, welches ferner den 55 
Schritt der Verwendung des Interface-Funktionsblok- 
kes fur eine Kommunikation mit dem externen Funk- 
tionsblock aufweist, um Daten, die dem externen Funk- 
tionsblock zugeordnet sind, unabhangig von der Ope- 
ration der internen Funktionsblocke zu erneuern. 60 

25. Verfahren nach Anspruch 23, welches ferner den 
Schritt einer Verwendung des Interface-Funktionsblok- 
kes umfaBt, um weitere Daten zu dem externen Funk- 
tionsblock zu iibertragen, um die Konfiguration des ex- 
ternen Funktionsblockes zu andern. 65 

26. Verfahren nach Anspruch 23, welches ferner fol- 
gende Schritte enthalt: 

- einem Anwender erlauben, die Steuer- oder Re- 



gelroutine dadurch zu konfigurieren, indem jeder 
eine Anzahl von Funktionsblocken, die in der 
Steuer- oder Regelroutine zu verwenden sind, 
spezifiziert wird, 

- die Verbindungen zwischen den spezifizierten 
Funktionsblocken, die in der Steuer- oder Regel- 
routine zu verwenden sind, zu identifizieren, und 

• - die Lage eines bestimmten spezifizierten Funk- 
tionsblockes als einen internen Funktionsblock zu 
spezifizieren, der in dem Kontroller implementiert 
ist, oder als externen Funktionsblock zu spezifi- 
zieren, der durch die Bereichsvorrichtung imple- 
mentiert ist. 

27. Verfahren nach Anspruch 26, bei dem der Schritt 
der Spezifizierung der Lage des bestimmten spezifi- 
zierten Funktionsblockes als den externen Funktions- 
block den folgenden Schritt aufweist: 

- Auswahlen einer, externen Vorrichtung, in wel- 
cher der externe Funktionsblock zu implementie- 
ren ist, aus einer Liste von externen Vorrichtun- 
gen, die an den Kontroller angeschlossen sind. 

28. Verfahren nach Anspruch 23, bei dem der Schritt 
der Speicherung der Daten, die dem externen Funk- 
tionsblock zugeordnet sind, den folgenden Schritt auf- 
weist: 

- Speichern einer Alarrnanzeige, die durch den 
externen Funktionsblock in dem Interface-Funk- 
tionsblock erzeugt wird, 

und bei dem das Verfahren des weiteren folgenden 
Schritt aufweist: ■ 

- Verwendung der Alarrnanzeige, die in dem In- 
terface-Funktionsblock gespeichert ist, zum Trig- 
gern einer Alarmverarbeitung innerhalb des Kon- 
trollers. 

29. Verfahren nach Anspruch 23, welches ferner den 
folgenden Schritt aufweist: 

- Darstellung der Steuer- oder Regelroutine 
durch Darstellen einer Wiedergabe der internen 
Funktionsblocke, einer Wiedergabe des Interface- 
Funktionsblocks und von Wiedergaben der Ver- 
bindungen zwischen den intemen Funktionsblok- 
ken und den Interface-Funktionsblocken, so daB 

. der Interface-Funktionsblock den externen Funk- 
tionsblock reprasentiert. 
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VCRs BASIEREND AUF DEN OATEN, 
DIE DURCH DIE FIELD-BUS-VORR. 
VEROFFENTUCHT WERDEN 



TRAGE IA5-INSTALLATI0NS- 
STATUS-PARAM ETER IN KON- 
TROLLER-STATUS-PARAMETER 
EIH 



210 

if 



220 



212 



213 



z 2 



14 



5MPEANGE. 
3ERAUSGE- 
BER-VERBIN- 
XJNGEN 



21 



ERZEUGE VEROFFENTUCHER- 
VERBINDUNGEN UND DIE ZOGE- 
ORDNETENVCRjFURDASFIELD- 
BUS-NETZWERK 



.222 



FIG. 8 



FIG. 7 
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EMPFANGE GESAMT-YOR- 

RICHTUNGS^KONFIGURATION- 

INSTALUTIONS-SCRIPT 



^31 



ODOSCHE FRUHERE 
KDNFIGUKATTON IN 
DER VGRRICffTUNG 



V 1 



32 



INSTALUERE VCRsZUOER 
VORRICHTUNG 



33 



INSTALUERE VERBINDUNGEN 
ZU DER VORRICHTUNG 



I 
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INSTALUERE FUNKTJONS- 
BLOCK-START-USTEZU DER 
VORRICHTUNG 



35 



INSTALUERE MAKROZYKLUS 
ZU DERYORRICHTUNG 



y 2 



36 
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EMPFANGE FUNKIIONS-BLOCK- 
INSTALLAT10NS-SCRIPT 



41 



INSTALUERE NACHSTEN FUNK- 
TIONS-BLOCK UMD AUSFUHRUNGS- 
PARAMETER 



242 



SETZE FUNKTTCNS- 
BL0CK-M3DUS AUF 
ABSSER BETRIEB 



43 



INSTALUERE FUNKTIONSBLOCK- 
PARAMETER- KONFIGURIERTE 
WERTE 
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44 



SETZEFUNICTIONSBLOCK-MODUS 
AUF DEN KONFIGURIERTEN 
WERT 
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FIG. 10 
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TASTE DIE BETRIEBS-DATEN FUR . 
DEN SCHATTEN BLOCK IN DERMODUL- 
ABTASTRATEAB 
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-ERNEUERE DEN BLOCK-FEHLER IN DEM 
SCHATTEN BLOCK 

-SETZE SCHATTENBLOCK-AUSGAMGSSTATUS 
AUFSCHLECHT 

-SETZE PORT-INTEGRITAT AUF SCHLECHT 



KOPIERE DIE EMPFANGENEN 
BETRIEBS-DATEN IN DEN 
SCHATTEN-FUNKTIONS-BLOCK 



X 2 
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LESE DIE STATISTISCHEN DATEN 
VON DER FIELDBUS-VORRICHTUNG 


Nl 


*. 




TRAGE FIELDBUS-ALARME (DATEN) 
IN KONTROLLER-ALARME (DATEN) 
EIN 


^264 


<— — — 




MARKIERE ADSGANG 
ALS BadNotConnected 



HEW 



MACHE DIE BETRIEBSDATEN FUR DEN 
KONTROLLERUBERDEN SCHATTEN- 
FUNKTIONSBLOCK SICHTBAR 
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SCHATTEN-BLOCKEMPFANGT 
DATEN ODER EIME SCHREIB- 
ANFRAGE UBER EINE VERBINDUNG 
ODER EIN ANWENDER-INTERFACE 



z 21 
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DIE DAtEN ODER DIE ANFRAGE 
WERDEN BZW. WIRD ZU EXTERNEM 
FUNKTIONSBLOCR GESENDET ODER 
WIRD AUF DEM FIELDBUS-BUS 
VEROFFENTLICHT 



82 



ANTWORT- STATUS WIRD ZDM SCHAT- 
TEN-FU N KTIONSBLOCK UND/ODER 
ZUM ANWENDER ZURUCKGELEITET 
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FIG. 12 
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